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DOCUMENTS FOR COMME RCE IN TRADTNr. 
PARTNER NETWORKS AND INTERFACE DEFTNTTTQNS RASED ON 

THE DOCUMENTS 

BACKGROUND OF THE TNVFNTTON 

Field Qfthgtovmipn 

The present invention relates to systems and protocols supporting 
transactions among diverse clients coupled to a network; and more particularly 
to systems and protocols supporting commercial transactions among platforms 
having variant architectures. 

Description of Related Art 

The Internet and other communications networks provide avenues for 
communication among people and computer platforms which are being used for 
a wide variety of transactions, including conunercial transactions in which 
participants buy and sell goods and services. Many efforts are imderway to 
facilitate conmiercial transactions on the Internet. However, with many 
competing standards, in order to execute a transaction, the parties to the 
transaction must agree in advance on the protocols to be utilized, and often 
require custom integration of the platform architectures to support such 
transactions. Commercial processes internal to a particular node not compatible 
with agreed upon standards, may require substantial rework for integration with 
other nodes. Furthermore, as a company commits to one standard or the other, 
the company becomes locked-in to a given standardized group of transacting 
parties, to the exclusion of others. 

A good overview of the challenges met by Intemet commerce 
development is provided in Tenenbaum, et aL, "Eco System: An Intemet 
Commerce Architecture", Computer, May 1997, pp. 48-55. 
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To open commercial transactions on the Internet, standardization of 
architectural frameworks is desired. Platforms developed to support such 
commercial frameworks include IBM Conmierce Pomt, Microsoft Internet 
Commerce Framework, Netscape ONE (Open Network Environment), Oracle 
NCA (Network Computing Architecture), and Sun/JAVASoft JECF (JAVA 
Electronic Commerce Framework). 

In addition to these proprietary frameworks, programming techniques, 
such as common distributed object model based on CORBA HOP (Common 
Object Request Broker Architecture Internet ORB Protocol), are being pursued. 
Use of the common distributed object model is intended to simplify the 
migration of enterprise systems to systems which can mter-operate at the 
business application level for electronic commerce. However, a consiuner or 
business using one framework is unable to execute transactions on a different 
framework. This limits the growth of electronic commerce systems. 

Companies implementing one framework will have an application 
progranuning interface API which is different than the API's supporting other 
frameworks. Thus, it is very difficult for companies to access each others 
business services, without requiring adoption of common business system 
interfaces. The development of such business system interfaces at the API level 
requires significant cooperation amongst the parties which is often impractical. 

Accordingly, it is desirable to provide a framework which facilitates 
interaction amongst diverse platforms in a communication network. Such 
system should facilitate spontaneous commerce between trading partners 
without custom integration or prior agreement on industry wide standards. 
Further, such systems should encourage incremental path to business 
automation, to eliminate much of the time, cost and risks of traditional systems 
integration. 
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Overall, it is desirable to provide an electronic commerce system that 
replaces the closed trading partner networks based on proprietary standards with 
open markets. 
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SUMMARY O F THE INVENTION 
The present invention offers an infrastructure for connecting businesses 
with customers, suppliers and trading partners. Under the infrastructure of the 
5 present invention, companies exchange information and services using self- 

defining, machine-readable documents, such as XML (Extensible Markup 
Language) based documents, that can be easily understood amongst the partners. 
Documents which describe the documents to be exchanged, called business 
interface definitions BIDs herein, are posted on the Internet, or otherwise 

10 communicated to members of the network. The business interface definitions 

tell potential trading partners the services the company offers and the documents 
to use when communicating with such services. Thus, a typical business 
interface definition allows a customer to place an order by submitting a 
purchase order, compliant with a docimient definition published in the BID of a 

15 party to receive the purchase order. A supplier is allowed to check availability 

by downloading an inventory status report compliant with a document definition 
published in the BID of a business system managing inventory data. Use of 
predefined, machine-readable business documents provides a more intuitive and 
flexible v^y to access enterprise applications. 

20 A node in the commerce network establishes an interface for 

transactions according to the present invention that comprises a machine- 
readable specification of an interface, along with a machine-readable data 
structure that includes interpretation information for the machine-readable 
specification of the interface. The machine-readable specification of the 

25 interface includes a definition of an input document and a definition of an 

output doctmient, that are accepted and produced by transaction processes for 
which the node acts as an interface. The definitions of the input and output 
documents comprise respective descriptions of sets of storage imits and logical 
structures for sets of storage units, such as according to a standard XML based 
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document. The machine-readable data structure that includes interpretation 
information according to various aspects of the invention includes data type 
specifications (e.g. string, array, etc.) for logical structures in the definitions of 
the input and output documents, content models (e.g. lists of possible values) for 
logical structures and/or data structures that map predefmed sets of storage units 
for a particular logic structure to respective entries in a list in order to provide a 
semantic definition of logical structures (e.g. mapping codes to product names). 

According to other aspects of the invention, the interface includes a 
repository in memory accessible by at least one node m the network that stores a 
library of logic structures and interpretation information for the logic structures. 
The repository can be extended to mclude a library of definitions of mput and 
output documents, a library of specifications of interfaces, and a library of 
specifications for participant interface nodes in the network. 

Thus, a participant in the transaction fi-amework of the, present invention 
executes transactions amongst nodes in a network that includes a plurality of 
nodes executing processes involved in the transactions. The method includes 
storing a machine-readable specification of an mterface for a transaction, the 
specification includes a definition of an input document and a definition of an 
output document. The definition of the input and output documents comprise 
respective descriptions of sets of storage units and logical structures for the sets 
of storage imits. In a preferred system, the definitions are expressed in a manner 
compliant with a standard XML document type definition DTD, extended by 
semantic mapping, content modeling and data typing of some elements. The 
participant in the transaction receives data comprising a document through a 
communication network. The participant parses the docimient according to the 
specification stored for a transaction to identify an input docimient for the 
transaction. After parsing the document, at least a portion of the input document 
is provided in a machine-readable format to a transaction process which 
produces an output. An output document is formed comprising the output of the 
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transaction process, based on the definition of an output document in the stored 
specification. The output document is transmitted on the communication 
network, typically back to the source of the input document, or elsewhere as 
suits the needs of a particular type of transaction. 
5 Thus the business interface definition bridges the gap between the 

documents specified for example according to XML and the programs which 
execute on the fi"ont end of the transaction processing services at particular 
nodes. Such firont ends are implemented for example by JAVA virtual 
machines, or by other common architectures providing for mterconnection of 

10 systems across a network. The business interface definition provides a 

technique by which a transaction protocol is programmed using the business 
interface definition document. The program for the protocol of the transaction 
is established by a detailed formal specification of a document type. 

The machine-readable specification of the interface of the transaction is 

1 5 made accessible to other platforms in the network. Participant platfonns 

include resources to design input documents and output documents according to 
the transaction interface specified at a complementary node. Thus, participant 
nodes include resources to access the definition of an input document for the 
complementary interface and a definition of an output document for the 

20 complementary interface. The stored specification for the accessing participant 

node is established by including at least part of the definition of the output 
document of the complementary mterface in the definition of the input 
document of the interface stored in the specification. 

The process of establishing the stored specification of an interface 

25 according to another aspect of the mvention includes accessing elements of the 

machine-readable specification fi-om a repository. The repository stores a 
library of logic structures, content models, and schematic maps for logic 
structures, and definition of documents that comprise logic structures used to 
build interface description. A repository accessible in the network facilitates the 
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building of interface descriptions which can be easily shared. Any differences 
between the input document created for a particular process and the output 
document expected as a return by a complementary process can be easily 
negotiated by communication on the network and agreeing on common logic 
structures to express particular information. 

The machine-readable specification of an interface of a transaction 
according to one aspect of the invention includes a document compliant with a 
definition of an interface document that is shared amongst members of the 
network. A defmition of the interface document includes logic structures for 
storing an identifier of a particular transaction and at least one of definitions and 
references to definitions of input and output documents for the particular 
transaction. That is, the interface description for a particular service may 
actually encompass a defmition of the input and output documents. 
Altematively, it may include pointers to a location in the repository, or 
elsewhere in the network, of such definitions. 

According to another altemative of the invention, the machine-readable 
specification mcludes a business interface defmition BID document compliant 
with a definition of an interface document that includes logical structures for 
storing an identifier of the interface, and for storing at least one of specifications 
and references to specifications of a set of one or more transactions supported 
by the interface. For each supported transaction, the document includes at least 
one of definitions and references to definitions of input and output documents 
for the particular transaction. 

According to another aspect of the invention, the storage units defined in 
the definitions of the input and output document comprise parsed data including 
character data encoding text characters, and mark-up data identifying sets of 
storage units according to the logical structures of the input and output 
documents. According to another aspect of the invention, at least one of the sets 
of storage units encodes the plurality of text characters providing a natural 
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language word. This facilitates the use of the definitions of input and output 
documents by human readers and developers of such documents. 

Accordmg to another aspect of the invention, the specification of the 
input and output documents includes interpretation information for at least one 
5 of the sets of storage units identified by the logical structure. The interpretation 

information in one example encodes definitions for sets of parsed characters. In 
another example, the interpretation information provides for content model 
specifications, such as requiring a specific logic structure to carry a member of a 
list of codes mapped to product descriptions in a catalog. In some systems, the 

10 storage units in a logic structure of a document may include sets of unparsed 

data, as suits the needs of a particular implementation. 

According to yet another aspect of the invention, the transaction process 
in a particular platform hds a transaction processing architecture v^hich is one of 
a plurality of variant transaction processing architectures. Thus the participant 

1 5 node includes resources for translating at least a portion of the input document 

into a format readable according to the variant transaction processing 
architecture of the transaction process utilizing the information. The elements 
of the document definition are translated into progranuning objects that include 
variables and methods according to the variant transaction processing 

20 architectures of the transaction process. For a participant having a JAVA virtual 

machine acting as a transaction process fi'ont end, particular fields in the 
documents are translated into JAVA objects, including the data as well as get 
and set fimctions associated with a JAVA object. Other transaction processing 
architectures supportable according to the present invention include processes 

25 compliant with an interface description language in the sense of Common 

Object Request Broker Architecture CORBA, Component Object Model 
COM,On-Line Transaction Processing OLTP, and Electronic Data Interchange 
EDI. 
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According to other aspects of the invention, a repository is provided that 
stores document types for use in the plurality of transactions. The machine- 
readable specification for a particular transaction defines at least one of the 
input and output documents by reference to a document type in the repository. 
According to another aspect, the document type included in the repository 
include a document type for identifying participants in the network. Such 
document type providing structures for identifying a participant, specifying the 
services supported by the participant, and specifying the input and.output 
documents for each of such services. 

In addition to the methods described above, the present invention 
provides an apparatus for managing transactions among nodes that includes a 
network interface, memory for storing data and programs of instructions 
including a machine-readable specification of an interface for a transaction as 
described above, and a data processor that is coupled with the inemory and the 
network interface. The programs of instructions stored in the apparatus include 
logic to execute the processes described above for a participant m the 
transactions. 

The present invention further provides an apparatus for establishing 
participant interfaces for transactions executed on a system that include a 
network interface, and a data processing resources that execute transaction 
processes according to a transaction processing architecture. The apparatus 
includes programs of instructions that are executable by the system and stored 
on a medium accessible by the system that provide tools to bxiild a definition of 
a participant interface for a participant in a particular transaction. The definition 
of a participant interface includes a definition of an input docxmient and a 
definition of an output document. The definitions of the input and output 
documents comprise respective machine-readable descriptions of sets of storage 
units in logical structures for the sets of storage units, which may be compliant 
in one aspect of the invention with XML document type definitions. 
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The apparatus for establishing participant interfaces according to this 
aspect of the invention also includes programs of instructions stored on a 
mediiim accessible by the data processing system and responsive to the 
definitions of input and output documents to compile data structures 
corresponding to the sets of storage units and logical structures of the input and 
output documents that are compliant with the transaction processing 
architecture, to compile instructions executable by the system to translate the 
input document to the corresponding data structures, and to compile instructions 
executable by the system to translate output of the transaction processes into 
sets of storage units and logical structures of the output document. 

The tools to build a definition of a participant interface in a prefeired 
system include mstriictions executable by the system to access elements of the 
definition fi*om complemcintary nodes and/or fi:om a repository that stores a 
library of logical structures and interpretation information for Ipgical structures 
used to build interfece descriptions. According to various aspects of the 
invention, the repository includes not only a library of logical structures but 
definitions of documents that comprise logical structures, and formats for 
specifying participant mterfaces. According to this aspect of the mvention, tools 
are provided for building specifications of business interfaces according to the 
techniques described above in connection with the description of the participant 
nodes. The tools for building interfaces and the tools for compiling the 
interfaces into resources needed for communication with transaction processing 
architectures according to this aspect of the invention, are implemented in 
participant nodes in the preferred system, and utilized for the development and 
optimization of the interface descriptions as use of the network grows based on 
interface descriptions that define input and output docxmients. 

Accordingly, another aspect of the invention provides an apparatus that 
includes memory and a data processor that executes instructions stored in the 
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memory that include tools to build a definition of a participant interface and a 
compiler performing the functions described above. 

According to yet another aspect of the invention, the use of the 
participant interface descriptions enables the operation of a market maker node. 
At such a node, a method for managing transactions is provided that comprises 
storing machine-readable specifications of a plurality of participant interfaces 
which identify transactions supported by the interfaces, and the respective input 
and output documents of such transactions. As described above, the definitions 
of the input and output documents comprise respective descriptions of sets of 
storage units and logical structures for the sets of storage xmits, such as 
according to the XML standard. In addition, the definitions of the transactions 
and the defmitions of the participant interfaces all comprise documents specified 
according to a technique compliant with XML or other standardized document 
e3q)ression language. At such market maker node, data comprising a document 
is received over a communication network. The document is parsed according 
to the specifications to identify an input document in one or more transactions 
which accept the identified input document. At least a portion of the input 
document is provided in a machine-readable format to a transaction process 
associated with the one or more identified transactions. The step of providing at 
least a portion of the input document to a transaction process mcludes executing 
a routing process according to a processing architecture at the market maker 
node. The routing process in one aspect of the invention is executed according 
to a particular processing architecture, and at least a portion of the incoming 
document is translated into the format of the processing architecture of the 
routing process. The translating according to the preferred aspect includes 
producing programming objects that include variables and methods according to 
the processing architecture of the routing process. 

According to another aspect of the invention, the market maker node 
also supports the repository structure. Thus, a process is included at the market 
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maker node for allowing access by participants in the network to a repository 
stored at the market maker node. As described above, the repository includes 
definitions of logic structures, interpretation information, and document 
definitions for use by the participant nodes to build transaction interface 
documents and includes instances of business interface definitions that identify 
the participants, and the transactions executed by the respective participants. 

The routing process includes according to various alternatives the 
translating of the input document into the variant processing architecture of the 
processes to which the document is to be routed, or routing the input document 
in its original document format across the network to a remote processing node, 
or to combinations of such processes. In alternatives, the routing process may 
also include techniques for transforming an input document defined according 
to one input document definition into a different document defined according to 
a different document specification for a process which has registered to watch 
for the input document. 

Also, the market maker node is provided according to the present 
invention as apparatus that includes a network interface, memory storing data 
and programs of instructions including the specifications of the participant 
interfaces, and a data processor. The logic is provided with the data processor 
m the form of programs of instructions or otherwise to perform the market 
maker process as discussed above. 

Accordingly, the present invention provides a foundation for electronic 
commerce based on the sharing of specifications of input and output documents. 
Documents provide an intuitive and flexible way to access business services, 
much simpler to implement than programming APIs. It is much easier to 
interconnect companies in terms of documents that are exchanged, on which 
such companies aheady largely agree, than in terms of business system 
interfaces which invariably differ. In addition, such documents are specified in 
a human readable format in the preferred embodiment. According to the present 



-12- 



wo 00/23925 



PCTAJS99/23426 



invention the business interfaces are specified in docunaents, such as XML 
documents that are readily interpretable by humans as well as by computers. 

Utilization of the document based transaction architecture of the present 
invention involves the use of a parser which operates in basically the same way 
for any source of documents, eliminatmg much of the need for custom programs 
to extract and integrate information from each participant in the network. Thus, 
integrating enterprise information from accounting, purchasing, manufacturing, 
shipping and other functions can be accorriplished by first converting each 
source to a document having an architecture according to the present invention, 
and then processing the parsed data stream. Each node in the system that 
participates in the market only needs to know about the format of its internal 
systems, as well as the format of the documents being specified for interchange 
according to the transaction. Thus, there is no need to be able to produce the 
native format of every other node which might want to participate in the 
electronic commerce network. 

For complete business integration, the present invention provides a 
repository of standardized logical structures, like XML elements, attributes or 
meta data, establishing a semantic language for particular commerce 
communities, a means for mapping between different meta data descriptions, 
and a server for processing the documents and invoking appropriate applications 
and services. The basic building blocks of a network according to the present 
invention include the business interface definitions which tell potential trading 
partners what online services a company offers and which documents to use to 
invoke the services; and servers which provide the bridge to bind together the 
set of internal, and external business services to create a trading conmixmity. 
The server operates to parse the incoming documents and invoke the appropriate 
services. Also the server according to the present invention handles the 
translation tasks from the format of the documents being received and 
transmitted, to and from the formats of the respective host systems. Thus, 
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trading partners need only agree on the stmcture, content and sequent 
business documents exchanged, and not on the details of application 
programmer interfaces. How a document is processed and the iactions which 
result from receipt of a document are strictly up to the businesses providing the 
5 services. This elevates integration from the system level to the business level. 

It enables the business to present a clean and stable interface to its partners 
despite changes in its internal technology implementation, organization or 
processes. 

The whole process of building business interface definitions and 
10 enabling servers to manage commerce according to such descriptions is 

facilitated by a common business library, or repository, of information models 
for generic business concepts including business description primitives like 
companies, services and products, business fonns like catalogs, purchase orders 
and invoices, and standard measurements, including time and 4ate, location and 
15 classification of goods. 

Other aspects of the present mvention can be seen upon review of the 
figures, the detailed description, and the claims which follow. 

BRIEF DESCRTPTIQN OF THF FTrxTipPS 
20 Fig. 1 is a simplified diagram of an electronic commerce network 

including business mterface defmitions BIDs according to the present invention. 

Fig. 2 is a simplified diagram of a business interfece definition document 
according to iho present invention. 

Fig. 3 is a conceptual block diagram of a server for a participant node in 
25 the network of the present invention. 

Fig. 4 is a flow chart illustrating the processing of a received document 
at a participant node according to the present invention. 

Fig. 5 is a block diagram of a parser and transaction process front end for 
an XML based system. 
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Fig. 6 is a conceptual diagram of the flow of a parse function. 

Fig. 7 is a simplified diagram of the resources at a server used for 
building a business interface definition according to the present invention. 

Fig. 8 is a simplified diagram of a repository according to the present 
invention for use for building busmess interface definitions. 

Fig. 9 is a flow chart illustrating the processes of building a business 
interface definition according to the present invention. 

Fig. 10 provides a heuristic view of a repository according to the present 
invention. 

Fig. 1 1 is a simplified diagram of the resources at a server providing the 
market maker function for the network of the present invention based on 
business interface definitions. 

Fig. 12 is a flow chart for the market maker node processing of a 
received docmnent. 

Fig. 13 is a flow chart illustrating the process of registering participants 
at a market maker node according to the present invention. 

Fig. 14 is a flow chart illustrating the process of providing service 
specifications at a market maker node according to the process of Fig. 9. 

Fig. 15 is a diagram illustrating the sequence of operation at a participant 
or market maker node according to the present invention^ 

Fig, 16 is a conceptual diagram of the elements of a commercial network 
based on BIDs, according to the present invention, 

DETAILED DRSrPTPTTnM 
A detailed description of the present invention is provided with respect 
to the figures, in which Fig. 1 illustrates a network of market participants and 
market makers based on the use of business interface defmitions, and supporting 
the trading of input and output documents specified according to such interface 
descriptions. The network includes a plurality of nodes 11-18 which are 
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interconnected through a communication network such as the Internet 19, or 
other telecommunications or data communications network. Each of the nodes 
11-19 consists of a computer, such as a portable computer, a desktop personal 
computer, a workstation, a network of systems, or other data processing 
resources. The nodes include memory for storing the business interface 
definition, processors that execute transaction processes supporting commercial 
transactions with other nodes in the network, and computer programs which are 
executed by the processors in support of such services. In addition each of the 
nodes includes a network interface for providing for communication across the 
Internet 1 9, or the other communication network. 

In the environment of Fig. 1, nodes 1 1, 12, 13, 14, 16 and 18 are 
designated market participants. Market participants include resources for 
consumers or suppliers of goods or services to be traded according to 
commercial transactions established according to the present invention. 

In this example, nodes 15 and 17 are market maker nodes. The market 
maker nodes include resources for registering business interface definitions, 
called a BID registry. Participants are able to send documents to a market 
maker node, at which the document is identified and routed to an appropriate 
participant which has registered to receive such documents as input. The 
market maker also facilitates the commercial network by maintaining a 
repository of standard forms making up a conunon business library for use in 
building busmess interface definitions. 

In this example, the market participant 1 8 is connected directly to the 
market maker 1 7, rather than through the Internet 1 9. This connection directly 
to the market maker illustrates that the configuration of the networks supporting 
commercial transactions can be very diverse, incorporating public networks 
such as the Internet 19, and private connections such as a local area network or a 
Point-to-Point connection as illustrated between nodes 17 and 18. Actual 
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communication networks are quite diverse and suitable for use to establish 
commercial transaction networks according to the present invention. 

Fig. 2 is a heuristic diagram of nested structures in a business interface 
definition BID which is established ifor market participants in the network 
according to the present invention. The business interface definition illustrated 
in Fig. 2 is a data structure that consists of logic structures and storage units 
arranged according to a formal definition of a document structure, such as a 
XML document type definition DTD. The structure of Fig. 2 includes a first 
logic structure 200 for identifying a party. Associated witii the logic structure 
200 are nested logic structures for carrying the name 201, the physical address 
202, the network address or location 203, and a set of transactions for a service 
204, For each transaction in the service set, an mterface definition is provided, 
including tiie transaction BID 205, the transaction BID 206, and the transaction 
BID 207. Within each transaction BID, such as transaction Bip 205, logical 
structures are provided for including a name 208, a location on the network at 
which the service is performed 209, the operations performed by the service 
210, and a set of input documents indicated by the tag 21 1. Also, the service 
BID 205 includes a set of output documents indicated by the tag 212. The set of 
input documents 21 1 includes a business interface definition for each input 
document for which the services are designed to respond, including input 
document business interface definitions 213, 214, and 215. Each business 
interface definition for an input document includes a name 216, a location on 
the network at which a description of the document can be found 21 7, and tiie 
modules to be carried in the document as indicated by the field 218. In a similar 
manner, the output document set 212 includes interface definitions for output 
documents including tiie output document BID 219, output document BID 220, 
and output document BID 22 1 . For each output document BID, a name 222, a 
location on tiie network or elsewhere 223, and the modules of the document 224 
are specified. The business interface definition for the participant as illustrated 
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in Fig. 2 includes actual definitions of a logic structures to be utilized for the 
input and output documents of the respective services, or pointers or other 
• references to locations at which these definitions can be found. 

In the preferred system, the document of Fig. 2 is specified in an XML 
5 document type definition DTD, although other document definition 

architectures could be used, and includes interpretation information for the 
logical structures used in interpretation of instances of the documents. In 
addition, each of the transaction BIDs, input document BIDs and output 
document BIDs are specified according to an XML document type definitions. 

10 The XML type document is an example of a system based on parsed data that 

includes mark-up data and character data. Mark-up data identifies logical 
structures within the document and sets of character data identify the content of 
the logical structures. In addition, unparsed data can be carried in the dociunent 
for a variety of purposes. See for example the specification of the Extensible 

15 Mark-up Language XML LO REC-XML-19980210 published by the WC3 XML 

Woikmg Group at WWW.W3.0RGmi/1998/REC-XML- 199802 10. 

Thus in an exemplary system, participant nodes m the network establish 
virtual enterprises by interconnecting business systems and seridces with XML 
encoded documents that businesses accept and generate. For example, the 

i20 business interface definition of a particular service establishes that if a 

document matching the BID of a request for a catalog entry is received, then a 
document matching a BID of a catalog entry will be returned. Also, if a 
docimient matching the BID of a purchase order is received, and it is acceptable 
to the receivmg terminal, a document matching the BID of an invoice will be 

25 returned. The nodes in the network process the XML documents before they 

enter the local business system, which is established according to the variant 
transaction processmg architecture of any given system in the network. Thus, 
tiie system unpacks sets of related documents, such as MIME-encoded sets of 
XML documents, parses them to create a stream of "mark-up messages". The 
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messages are routed to the appropriate applications and services using for 
example an event listener model like that described below. 

The documents exchanged between business services are encoded using 
an XML language buih from a repository of building blocks (a common 
business language) from which more complex document definitions may be 
created. The repository stores modules of interpretation information that are 
focused on the functions and information common to business domains, 
including business description priniitives like companies, services and products; 
business forms like catalogs, purchase orders and invoices; standard 
measurements, like time, date, location; classification codes and the like 
providing interpretation information for logical structures in the XML 
documents. 

The business interface definition is a higher level document that acts as a 
schema used for designing interfaces that trade documents according to the 
present invention. Thus the business interface definition bridges the gap 
between the documents specified according to XML and the programs which 
execute on the fi^ont end of the transaction processing services at particular 
nodes. Such front ends are implemented by JAVA virtual machines, or by other 
common architectures providing for intercoimection of systems across a 
network. Thus, the business interface definition provides a technique by which 
a transaction protocol is programmed usmg the business mterface definition 
document The program for the protocol of the transaction is established by a 
detailed formal specification of a document type. 

An example business interface definition BID based on a market 
participant document v^hich conforms to an XML format is provided below. 
The market participant DTD groups business information about market 
participants, associating contact and address information with a description of 
services and financial information. This business information is composed of 
names, codes, addresses, a dedicated taxonomic mechanism for describmg 
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business organization, and a pointer to terms of business. In addition, the 
services identified by the market participant DTD will specify the input and 
ou^ut documents which that participant is expected respond to and produce. 
Thus, documents which define schema using an exemplary common business 
language for a market participant DTD, a service DTD, and a transaction 
document DTD specified in XML with explanatory comments follow: 
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Market Participant Sample 

<!DOCTYPE SCHEMA SYSTEM "bidLdtd"> 
<SCHEMA> 

5 <Hl>Market Participant Sample BID</H1> 

<META 

WHO.OWNS=-Veo Systems" WHO.COPYRIGHT="Veo Systems" 
WHEN.COPYRIGHT="1998" DESCRIPTION="Sample BID" 
WHO.CREATED="*" WHEN.CREATED^"*" 
10 WHAT.VERSION="*» WHO.MODIFIED-"*- 

WHEN.MODIFIED="*" WHEN.EFFECTIVE="*" 
WHEN.EXPIRES="*" WHO.EFFECTIVE="*" 
WHO.EXPIRES="*"> 
<yMETA> 

15 

<PROLOG> 

<XMLDECL STANDALONE= W></XMLDECI> 
<DOCTYPE NAME="market.participant"> 
<SYSTEM>markparLdtd</SYSTEM></DOCTYPE> 
20 </PROLOG> 

<DTD NAME="mariq)artdtd"> 
<H2>Market Participant<;^> 
<H3>Market Participant<;/H3> 

25 <ELEMENTTYPE NAME="maiket.participant"> 

<EXPLAIN><nTLE>A Market Participant<ynTLE> 

<SYNOPSIS>A business or person and its service interfaces.</SYNOPSIS> 

<P>A market participant is a document definition that is created to describe a business and at 

least one person with an email address, and it presents a set of pointers to service interfaces 

30 located on the network. In this example, the pointers have been resolved and the complete BID 

is presented here.<VP></EXPLAIN> 
<MODELxCHOICE> 

<ELEMENT NAME="business"><yELEMENT> 
<ELEMENT NAME="pereon"></ELEMENT> 
35 </CHOICE><yMODEL></ELEMENTTYPE> 
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<H3>Paity Prototype</H3> 
<PROTOTYPE NAME="party"> 

<EXPLAIN><nTLE>The Party Pn)totype</nTLE></EXPLAIN> 
<MODEL><SEQUENCE> 
5 <ELEMENT NAME="party.name" OCajRS="+"></ELEMEN'I> 

<ELEMENT NAME="address.set"X/ELEMENT> 
</SEQUENCE><;/MODEL> 
</PROTOTYPE> 

10 <H3>PartyTypes<;«3> 

<ELEMENTTYPE NAME="business"> 
<EXPLAIN><TITLE>A Business</nTLE> 

<SYNOPSIS>A business (party) with a business number attribute.</SYNOPSIS> 
<P>This element inherits the content model of the party prototype and adds a business number 
1 5 attribute, which serves as a key. for database lookup. The business number may be used as a 

cross-reference to/from customer id, credit limits, contacts lists, etc.</P></EXPLAIN> 
<EXTENDS HREF=''party"> 

<ATTDEFNAME="business.number"><REQUIRED></REQUIRED><ATTDEF> 

</EXTENDS> 

20 </ELEMENTTYPE> 

<H3>Person Name</H3> 
<ELEMENTTYPE NAME="person*'> 
<EXPLAIN><nTLE>A Person</nTLE></EXPLAIN> 
25 <EXTENDS HREF="party''> 

<ATTDEF NAME="SSN'><IMPLIED></IMPLIED><yATTDEF> 

</EXTENDS> 
</ELEMENTTYPE> 

30 <H3>PartyName<yH3> 

<ELEMENTTYPE NAME="party.name"> 
<EXPLAIN><TnLE>A Party's Name</TrrLE> 

<SYNOPSIS>A party's name in a string of character.<SYNOPSIS></EXPLAIN> 
<MODEI><STRING></STRING></MODEL> 
35 <yELEMENTTYPE> 
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<H3>Address Set<yH3> 
<ELEMENTTYPE NAME="address.set"> 

<MODEL><SEQUENCE> 

<ELEMENTNAME==''address,physicar'></ELEMENT> 
<ELEMENT NAME="teIephone" OCCURS-" *"></ELEMENT> 
<ELEMENTNAME="fax" OCCURS="*"><yELEMEN'I> 
<ELEMENT NAME="emaiI" OCCURS-"* "><ELEMENT> 
<ELEMENTNAME="intemet" OCCURS="*"></ELEMENT> 
</SEQUENCEx;/MODEL> 
</ELEMENTTyPE> 

<H3>Physical Address</H3> 
<ELEMENTTYPE NAME="address.physical"> 
<EXPLAlN><TITLE>Physical Address</nTLE> 

<SYNOPSIS>The street address, city, state, and zip code.</SYNOPSIS><yEXPLAIN> 

<MODEL><SEQUENCE> 

<ELEMENT NAME="street"></ELEMENT> 

<ELEMENTNAME=="city"x/ELEMENT> " 

<ELEMENT NAME="state"></ELEMENT> 

<ELEMENT NAME="postcode" OCCURS="?"><;/ELEMENI> 

<ELEMENT NAME-"country"><yELEMEN'I> 

<SEQUENCE><yMODEL> 

<VELEMENTTYPE> 

<H3>Street<7H3> 

<ELEMENTTYPE NAME="street"> 
<EXPLAIN><TITLE>Street Address</TITLE> 
<SYNOPSIS>Street or postal address.</SYNOPSISxyEXPLAIN> 
<MODEL><STRING></STRING><yMODEL> 
<;^LEMENTTYPE> 

<H3>City</H3> 

<ELEMENTTYPE NAME="city"> 
<EXPLAIN><nTLE>City Name or Code<nnTLE> 
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<P>The city name or code is a string that contains sufficient infonnation to identify a city within 
a designated state.</P> 

<;/EXPLAIN> 

<MODEL><STRING><;/STRINGx/MODEL> 
</ELEMENTTYPE> 

<H3>State</H3> 

<ELEMENTTYPE NAME="state'*> 

<EXPLAIN><nTLE>State, Province or Prefecture Name or Code</TITLE> 

<P>The state name or code contains sufficient infonnation to identify a state within a designated 

countiy.</Px/EXPLAIN> 

<MODEL><STRmGDATATYPE=XOUNTRY.US.SUBENTITY'><VST^ 
<yELEMENTTYPE> 

<H3>Postal Code</H3> 
<ELEMENTTYPE NAME="postcode"> 
<EXPLAIN><nTLE>Postal Code</TITLE> 

<P>A postal code is an alphanumeric code, designated by an appropriate postal authority, that is 
used to identify a location or region within the jurisdiction of that postal authority. Postal 
authorities include designated national postal authorities.<;/P></EXPLAIN> 

<M0DEl><STRmGDATATYPE="string"></STRING><;/MODEI^ 
</ELEMENTTYPE> 

<H3>Country<yH3> 
<EIJSMEmTYPE NAME="country"> 
<EXPLAIN><TITLE>Countiy Code</nTLE> 

<P>A country code is a two-letter code, designated by ISO, that is used to uniquely identify a 
country.<yPxyEXPLAIN> 

<MODEL><STRING DATATYPE="country"><;/STRING></MODEL> 
</ELEMENTTYPE> 

<H3>Network Addresses</H3> 
<ELEMENTTYPE NAME="telephone"> 
<EXPLAIN><nTLE>TeIephone Number<mTLE> 



-24- 



wo 00/23925 ^ PCT/US99/23426 



<P>A telephone number is a string of alphanumerics and punctuation that uniquely identifies a 
telephone service teiminal, including extension number</P></EXPLAIN> 
<M0DELXSTRING></STRING></M0DEL> 
<VELEMENTTyPE> 

5 

<H3>Fax<H3> 

<ELEMENTTYPE NAME="fex'> 
<EXPLAINxnTLE>Fax Number</TITLE> 

<P>A fax number is a string of alphanumerics and punctuation that uniquely identifies a fax 
1 0 service tenninal.<yp> 

<yEXPLAIN> 

<MODEL><STRING></STRING></MODEL> 
</ELEMENTTYPE> 



15 <H3>Email<yH3> 

<ELEMENTTyPE NAME="email"> 
<EXPLAINxnTLE>Email Address</nTLE> 

<P>An email address is a datatype-constrained string that uniquely identifies a mailbox on a 

server.</P></EXPLAIN> 
20 <MODEL><STRING DATATYPE="email"xySTRING></MODEL> 

</ELEMENTTYPE> 

<H3>Intemet Address<;^> 
<ELEMENTTYPE NAME^"intemet"> 
25 <EXPLAm><TriLE>InternetAddress</TITLE> 

<P>An Internet address is a datatype-constramed string that uniquely identifies a resource on the 
Internet by means of a URL.</P></EXPLAIN> 
<MODEL><STRING DATATYPE="url"><ySTRING></MODEL> 
<yELEMENTTYPE> 

30 

</DTD> 
</SCHEMA> 

Service Description Sample 

35 
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<!DOCTYPE schema SYSTEM "bidLdtd"> 
<SCHEMA> 

<Hl>Service Description Sample BID</H1> 
<META 

5 WHO.OWNS="Veo Systems" WHO.COPYRIGHT="Veo Systems" 

WHEN.COPYRIGHT="1998" DESCRIPTION="Sample BID" 
WHO.CREATED="*" WHEN.CREATED="*" 
WHAT.VERSION==-*" WHO.MODIFIED="*" 
WHEN.MODIFIED="*" WHEN.EFFECTIVE="*" 
10 WHEN.EXPIRES="*" WHO.EFFECTIVE="*" 

WHO.EXPIRES="*"> 
</META> 

<PROLOG> 

15 <XMLDECLSTANDALONE=W><VXMLDECL> 
<DOCTYPE NAME="service**> 
<SYSTEM>semce.dtd<;/SYSTEM><yDOCTYPE> 
<VPROLOG> 



20 <DTDNAME="service.dtd"> 
<H2>Services</H2> 

<H3>Includes<yH3> 

<!- INCLUDE><SYSTEM>comments.bim</SYSTEM></INCLUDE ~> 

25 

<H3>Service Set<;^> 
<ELEMENTTYPE NAME="service.sef > 
<EXPLAIN><TITLE>Service Set</TITLE> 
<SYNOPSIS>A set of services.</SYNOPSISx/EXPLAIN> 
30 <MODEL> 

<ELEMENT NAME="service" OCCURS="+"x/ELEMENT> 
</MODEI><VELEMENTTYPE> 



<H3>Services Prototype*^3> 
35 <PROTOTYPE NAME="prototype.service"> 
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<EXPLAIN><TITLE>Service</TITLExyEXPLAIN> 
<M0DELXSEQUENCE> 

<ELEMENT NAME="service.name"X/ELEMENT> 
<ELEMENT NAME="service.terms" OCCURS="+"><;/ELEMENT> 
5 <ELEMENT NAME="service. location" OCCURS="+"></ELEMENT> 

<ELEMENT NAME="service,operation" 0CCURS="+"></ELEMEN1> 
</SEQUENCE><MODEL> 
<!- ATTGR0UP><IMPLE^4ENTS 

HREF="cominon.attrib"><yiMPLEMEhrrS><yATTGROUP -> 
10 <;/PROTOTYPE> 

<H3>Service</H3> 

<INTROxP>A service is an addressable network resource that provides interfaces to specific 
operations by v^^ay of input and output documents.</P><;/INTRO> 
1 5 <ELEMENtTYPE NAME=*;service'^> 

<EXPLAIN><TITLE>Service</TITLE> 

<P>A service is defined in terms of its name, the location(s) at which the^ service is available, 

and the operation(s) that the service performs.</P><EXPLAIN> 

<MODEL><SEQUENCE> 
20 <ELEMENTNAME-"service.name"></ELEMENT> 

<ELEMENT NAME="service. location "></ELEMENT> 

<ELEMENTNAME="service.operation" OCCURS="+"></ELEMENT> 

<ELEMENT NAME-"service.terms"></ELEMENT> 

</SEQUENCE><;/MODEL> 
25 </ELEMENTTYPE> 

<H3>Service Name<yH3> 
<ELEMENTTYPE NAME="service,name"> 
<EXPLAIN><nTLE>Service Name</nTLE> 
30 <P>The service name is a human-readable string that ascribes a moniker for a service. It may be 

employed is user interfaces and documentation, or for other purposes.</P><;/EXPLAIN> 
<MODEL><STRING><ySTRING></MODEL> 
</ELEMENTTYPE> 

35 <H3>Service Location<yH3> 
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<ELEMENTTYPE NAME="service.location"> 
<EXPLAIN><nTLE>Service Location</nTLE> 
<SYNOPSIS>A URI of a service.<ySYNOPSIS> 

<P>A service location is a datatype-constrained string that locates a service on the Internet by 

means of a URI.</P><;/EXPLAIN> 

<M0DELXSTRING DATATYPE="url"><VSTRING><yMODEL> 
<ELEMENTTYPE> 

<H3>Service Operations<yH3> 

<INTRO><P>A service operation consists of a name, location and its interface, as identified by 
the type of input document that the service operation accepts and by the type of document that it 
will return as a result.</P></INTRO> 
<ELEMENTTYPE NAME-"service.operation"> 
<EXPLAIN><TlTLE>Service Operations</TITLE> 

<P>A service operation must have a name, a location, and at least one document type as an 
input, with one or more possible document types returned as a result of the operation.</P> 
</EXPLAIN> 
<MODELxSEQUENCE> 

<ELEMENTNAME="service.operation,name"><ELEMENT> 

<ELEMENTNAME="service.operation.location"></ELEMENT> 

<ELEMENT NAME="service.operation,input"></ELEMEN'I> 

<ELEMENTNAME="service.operation.output"x/ELEMENT> 

</SEQUENCEX/MODEL> 

<VELEMENTTYPE> 

<H3>Service Operation Name</H3> 
<ELEMENTTYPE NAME="service.operation.name''> 
<EXPLAIN><nTLE>Service Operation Name</nTLE> 

<P>The service operation name is a human-readable string that ascribes a moniker to a service 

operation. It may be employed in user interfaces and documentation, or for other 

puiposes.</P></EXPLAIN> 

<M0DEL><STRINGx/STRING><7M0DEL> 

<yELEMENTTYPE> 

<H3>Service Operation Location</H3> 
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<INTRO><P>The service location is a network resource. That is to say, a URI.-^/Px/INTRO> 
<ELEMENTTYPE NAME="service.operation.location"> 
<^XPLAIN><TITLE>Service Operation Location</TITLE> 
<SYNOPSIS>A URI of a service operation,</SYNOPSIS> 
5 <P>A service operation location is a datatype-constrained string that locates a service operation 

on the Internet by means of a URL.</P><yEXPLAIN> 
<MODEL><STRING DATATYPE="url"><;/STRING></MODEL> 
</ELEMENTTYPE> 

1 0 <H3>Service Operation Input Docunient</H3> 

<INTROxP>The input to a service operation is defined by its input document type. That is, the 

service operation is invoked when the service operation location receives an input document 

whose type corresponds to the document type specified by this element. </P> 

<P>Rather than define the expected input and output document types in the market participant 
1 5 document, this example provides pointers to externally-defined BIDs. This allows reuse of the 

same BID as the input and/or output document type for multiple operations. In addition, it 
. encourages parallel design and implementation.<yp><yiNTRO> 

<ELEMENTTYPE NAME="service.operation.input"> 

<EXPLAIN><TITLE>Service Operation Input<yTITLE> 
20 <SYNOPSIS>Identifies the type of the service operation input document.</SYNOPSIS> 

<P>Service location input is a datatype-constrained string that identifies a BID on the Internet 

by means of a URI.</P> 

<yEXPLAIN> 

<MODEL><STRING DATATYPE="urr'x/STRING><yMODEL> 
25 </ELEMENTTYPE> 



<H3>Service Operation Output Document Type</H3> 

<INTROxP>The output of a service operation is defined by its output document type(s). ITiat 
is, the service operation is expected to emit a document whose type coiresponds to the document 
30 type specified by this element </P></INTRO> 

<ELEMENTTYPE NAME="service,operation.outpur> 
<EXPLAIN><TITLE>Service Operation Output<;rnTLE> 

<SYNOPSIS>Identifies tfie type of the service operation output document.</SYNOPSlS> 
<P>Service location output is a datatype-constrained string that identifies a BID on the Internet 
35 by means of a URI.</P> 
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<VEXPLAIN> 

<MODELxSTRING DATATYPE="url"xySTRINGx/MODEI> 
</ELEMENTTYPE> 

5 <H3>Service Terms</H3> 

<INTRO><P>This is a simple collection of string elements, describing the terms of an 
agreement.</P><;/INTRO> 
<ELEMEOTTYPE NAME«"service.tenns"> 
<EXPLAIN><TITLE>Service Terms<mTLE> 
10 <SYNOPSIS>Describes the terms of a given agreement.</S YNOPSIS> 

<yEXPLAIN> 

<MODELxSTRING DATATYPE="string"XSTRING><;/MODEL> . 
<yELEMENTTYPE> 

15 </DTD> 

</SCHEMA> 



20 



The service DTD schema may be extended with a service type element 
in a common business language repository as follows: 



<!ELEMENT service.type EMPTY> 
<!ATTLIST service.type 

service.type.name ( 
catalog.operator 
25 I commercial.diFectoiy .operator 

I eft.services.provider 
I escrower 
I fulfillmentservice 
I insurer 

30 I manufacturer 

I marketoperator 
I order.originator 
I ordering.service 
I personal.services.provider 
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I retailer 

I retail.aggregator 

I schema.resolution.service 

I service.provider 

I shipmenLacceptor 

I shipper 

I van 

I whoiesale.aggregator 

)#REQUIRED 

%common.attrib; 



The service type element above illustrates interpretation information 
carried by a business interface definition, in this example a content form 

1 5 allowing identification of any one of a list of valid service types. Other 

interpretation information mcludes data typing, such as for example the element 
<H3>Intemet Address</H3> including the content form "url" and expressed in 
the data type "string." Yet other interpretation uiformation includes mapping of 
codes to elements of a list, such as for example the element <H3>State<yH3> 

20 including the code mapping for states in the file 

"COUNTRY.US.SUBENTITY." 

The service description referred to by the market participant DTD 
defines the documents that the service accepts and generates upon competition 
of the service. A basic service description is specified below as a XML 

25 document transact.dtd, 

Transact.dtd models a transaction description, such as an invoice, or a 
description of an exchange of value. This document type supports many uses, 
so the transaction description element has an attribute that allows user to 
distinguish among invoices, performance, offers to sell, requests for quotes and 

30 so on. The exchange may occur among more than two parties, but only two are 

called out, the offeror and the counter party, each of whom is represented by a 
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pointer to a document conforming to the market participant DTD outlined 
above. The counter party pointer is optional, to accommodate offers to sell 
The exchange description is described in the module tranprim.mod listed below, 
and includes pricing and subtotals. Following the exchange description, charges 
5 applying to the transaction as a whole may be provided, and a total charge must 

be supplied. Thus, the transaction description schema document transact.dtd for 
this example is set forth below: 

<!- transactdtd Version: 1.0 

<!- Copyright 1998 Veo Systems, Inc. 



<!ELEMENT transaction.description (meta?, issuer.pointer, 

coiinterparty;pointer?, exhange.descrption+, general.chai^es?; 
15 . net.total?)> 

<! ATTLIST transaction.description 

transaction.type (invoice | pro.fonna | offer .tcsell | order 
I request.for.quote | request.for.bid 
I requestfonproposal | response.to.requestfor.quote 
20 I response.to.request.for.bid 

I response.to.request.for.proposal) "invoice" 
%common.attrib; 
%altrep.attrib; 
%ttl.attrib; 

25 > 



Representative market participant, and.service DTDs, created according 
to the definitions above, are as follows: 

30 Market Participant DTD 

<!ELEM£NT business (party .name+ , address.set) > 

<! ATTLIST business business.number CDATA #REQUIRED 
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<!ELEMENT paity.name (#PCDATA )> 
<!ELEMENT city (#PCDATA )> 
<!ELEMENT internet (#PCDATA )> 
<!ELEMENT country (#PCDATA )> 
<!ELEMENT state (#PCDATA )> 
<!ELEMENT email (#PCDATA )> 

<!ELEMENT address.physical (street , city , state , postcode? , country) > 
<!ELEMENT telephone (#PCDATA )> 
<!ELEMENT person (party.name+ , address.set) > 
<!ATTLIST person SSN CDATA #IMPLIED 

<!ELEMENT fax (#PCDATA )>' 
<!ELEMENT street (#PCDATA )> 

<!ELEMENT address.set (address.physical , telephone* , fax* , email* , internet*) > 
<!ELEMENT postcode (#PCDATA )> 
<!ELEMENTmarket.participant (business | person) > 

Service DTD 

<!ELEMENT service. location (#PCDATA )> 
<IELEMENT service.terais (#PCDATA )> 
<!ELEMENT service.operation.name (#PCDATA )> 

<!ELEMENT service.operation (service.operation.name , service.operation.location , 
serv!ce.operation.input , service.operation.output) > 

<!ELEMENT service (service.name , service.location , service.operation+ , serviccterms) > 

<!£LEMENT service.operation.input (#PCDATA )> 

<!ELEMENT service.operation.location (#PCDATA )> 

<!ELEMENT service.name (^PCDATA )> 

<!ELEMENT service.set (service+ )> 

<IELEMENT service.operation.output (#PCDATA )> 

One instance of a document produced according to the transact.dtd 
follows: 
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<?xml version="1.0"?> 

<!- rorder.xml Version: 1 .0 — > 

<!" Copyright 1998 Veo Systems, Inc. -> 

<!DOCTYPE transaction.description SYSTEM "um:x- 
veosystems:dtd:cbl:transact: 1 .0:> 
<transaction.description transaction.type="order"> 
<meta> 

<um?um:x-veosystems:doc:0Q023 
</um> 

<thread.id party.assigned.by="reqorg">FRT876 
<ythread.id> 

</meta> 

<issuer.pointer> 

<xlI.locator urllink="reqorg.xmI">Custonier 

Pointer 

</xlI.Iocator> 
<yissuer.pointer> 
<counterparty.pointer> 

<xli.locator urllink="compu.xmr'>Catalog entry owner 

pointer 

<;/xll.locator> 
<ycounteq>arty.pointer> 
<exchange.descriptiQn> 
<line.item> 

<^roductinstance> 
<productdescription.pointer> 

<xlLIocator urllinlc="cthink.xnil">Catalogue Entry Pointer 

</xll.locator> 
</product.description.pointer> 
<product.specifics> 
<info.description.set> 
<info.description> 
<XmLdescriptor> 
<doctype> 
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<dtd systein.id=="uni:x-veosysteins:dtd:cbl:gprod: 1 .0"/> 
</doctype> 

<xniLdescriptondetails> 

<xll.xptr.frag>DESCENDANT(ALL,os)STRING("Windows 



95") 



</xll.xptr.fTag> 

<xll.xptr.fTag>DECENDANT(ALL,p.speed)STRINGC*200") 
<xll.xptr.frag> 

<xlLxptr.frag>DESCENDANT(ALLMd.disk.capacity) 
10 STRING("4") 

</xll.xptr.frag> 

<xll.xptr.frag>DESCENDANT(ALL,d.size)STRING("14.1") 

</xll.xptr.frag> 

</xml.descriptor.details> 
15 <;/xml.descriptor> : 

</mfo.description> 

</info.description.set> 

</prpductspecifics> 
<^uantity>l 
20 </quantity> 

</product.mstance> 
<shipment.coordinates.set> 
<shipment.coordinates> 
<shipment.destination> 
25 <address.set> 

<address.named>S W- 1 

</address,named> 

<address.physical> 

<building.sublocation>208C</building.sublocation> 
30 <location.in.street>123 

<;/location.in.street> 

<street>Frontage Rd. 

</street> 

<city>Beltway 
35 </city> 
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<country.subentity.U5 

countiy.subentity.us.name="MD"/> 

<postcode>20000 

<Vpostcode> 
<yadciress.physical> 
<teiephone> 

<telephone.number>6 1 7-666-2000 

</telephone.nuinber> 

<telephone.extension>1201 

</telephone.extension> 
</telephone> 
</address.set> 
</shipmentdestination> 

<shipment.special>No deliveries aifter 4 PM<Vshipmentspecial> 

</shipmenLcoordinates> 

</shipmentcoordinates.set> 

<payment.set> 

<credit.card 

issuer.name="VISA" 

instrument.number="3787-812345-67893" 

expiry.date=" 12/97" 

currency.code="USD"/> 

<amount.group> 

<amount.monetary cuiTency.code="USD*>3975 
</amountmonetary> 

</amount.group> 

</payinentset> 
</line.item> 
</exhange.description> 
</transaction.description> 

Accordingly, the present invention provides a technique by which a 
market participant is able to identify itself, and identify the types of input 
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documents and the types of output documents with which it is willing to transact 
business. The particular manner in which the content carried in such documents 
is processed by the other parties to the transaction, or by the local party, is not 
involved in establishing a business relationship nor carrying out transactions. 

Fig. 3 provides a simplified view of a participant node in the network 
according to the present invention. The node illustrated in Fig. 3 includes a 
network interface 300 which is coupled to a communication network on port 
301 . The network interface is coupled to a document parser 301. The parser 
301 supplies the logical structures from an incoming document to a translator 
module 302, which provides for translating the incoming document into a form 
usable by the host transaction system, and vice versa translating the output of 
host processes into the format of a document which matches the output 
document form in the business interface definition for transmission to a 
destination. The parser 301 and translator 302 are responsive to the business 
interface definition stored in the participant module 303. 

The output data structures from the translator 302 are supplied to a 
transaction process front end 304 along with events signaled by the parser 301 . 
The front end 304 in one embodiment consists of a JAVA virtual machine or 
other similar interface adapted for communication amongst diverse nodes in a 
network. The transaction processing front end 304 responds to the events 
mdicated by the parser 301 and the translator 302 to route the incoming data to 
appropriate functions in the enterprise systems and networks to which the 
participant is coupled. Thus, the transaction process front end 304 in the 
example of Fig. 3 is coupled to commercial functions 305, database functions 
306, other enterprise functions such as accounting and billing 307, and to the 
specific event listeners and processors 308 which are designed to respond to the 
events indicated by the parser. 

The parser 301 takes a purchase order like that in the example above, or 
other document, specified according to the business interface definition and 
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creates a set of events that are recognized by the local transaction processing 
architecture, such as a set of JAVA events for a JAVA virtual machine. 

The parser of the present invention is uncoupled from the programs that 
listen for events based on the received documents. Various pieces of mark-up in 
a received document or a complete document meeting certain specifications 
serve as instructions for listening functions to start processing, thus listening 
programs carry out tiie business logic associated witfi tiie document information. 
For example, a program associated with an address element may be code that 
validates tiie postal code by checking tiie database. These listeners subscribe to 
events by registering witii a document router, which directs the relevant events 
to all subscribers who are interested in them. 

For example, tiie purchase order specified above may be monitored by 
programs listening for events generated by tfie parser, which would connect tiie 
document or its contents to an order entry program. Receipt of product 
descriptions within the purchase order, might invoke a program to check 
inventory. Receiptof address mformation within the purchase order, would 
then invoke a program to check availability of services for delivery. Buyer 
information fields in the document, could invoke processes to check oixier 
history for credit worthiness or to offer a promotion or similar processing based 
on knowing the identity of the consumer. 

Complex listeners can be created as configurations of primitive ones. 
For example, a purchase order listener may contain and invoke tiie list listeners 
set out m tiie previous paragraph, or tiie list members may be invoked on tiieir 
own. Note tiiat tiie applications tiiat tiie listeners run are unlikely to be native 
XML processes or native JAVA processes. In tiiese cases, the objects would be 
transformed into the format required by the receiving trans application. When 
tfie application finishes processing, its output is tiien transformed back to the 
XML format for communication to other nodes in the network. 
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It can be seen that the market participant document type description, and 
the transaction docimient type description outlined above include a schematic 
mapping for logic elements in the documents, and include mark-up language 
based on natural language. The natural language mark-up, and other natural 
language attributes of XML facilitate the use of XML type mark-up languages 
for the specification of business interface definitions, service descriptions, and 
the descriptions of input and output documents. 

The participant module 303 m addition to storing the business interface 
definition includes a compiler which is used to compile objects or other data 
structures to be used by the transaction process front end 304 which corresponds 
to the logical structures in the incoming documents, and to compile the 
translator 302. Thus, as the business interface definition is modified or updated 
by the participant as the li-ansactions with which the participant is involved 
change, the translator 302 and parser 30 1 are automatically kept up to date. 

In a preferred system, the set of JAVA events is created by a compiler 
v^ch corresponds to the grove model of SGML, mainly the standard Element 
Structure Information Set augmented by the "property set" for each element. 
International Standard ISO/IEC 10179:1996 (E), Information Technology - 
Processing Languages Document Style Semantics and Specification 
Language (DSSSL), Turning the XML document into a set of events for the 
world to process contrasts with the normal model of parsing in which the parser 
output is maintained as an internal data structure. By translating the elements of 
the XML docmnent into JAVA events or other programming structures that are 
suitable for use by the transaction processing front end of the respective nodes 
enables rich functionality at nodes utilizing the documents being traded. 

Thus, the transaction process firont end 304 is able to operate in a publish 
and subscribe architecture that enables the addition of new listener programs 
without the knowledge of or impact on other listening programs in the system. 
Each listener, 305, 306, 307, 308 in Fig. 3, maintains a queue in which the front 
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end 304 directs events. This enables multiple listeners to handle events in 
parallel at their own pace. 

Furthermore, according to the present invention the applications that the 
hsteners run need not be native XML fiinctions, or native functions which 
match the format of the incoming document. Rather, these listeners may be 
JAVA functions, if the transaction process front end 304 is a JAVA interface, or 
may be functions which run according to a unique transaction processing 
architecture. In these cases, the objects would be transformed into the format 
required by the receiving application. When tiie application of the listener 
finishes, its output is tiien transformed back into the fomat of a document as 
specified by the business mterface definition in the module 303. Thus, the 
translator 302 is coupled to the network interface 300 directiy for supplying the 
composed documents as outputs. 

The listeners coupled to the transaction processing front end may include 
listeners for input documents, listeners for specific elements of the input 
documents, and listeners for attributes stored in particular elements of the input 
document. This enables diverse and flexible implementations of transaction 
processes at the participant nodes for filtering and responding to incoming 
documents. 

Fig. 4 illustrates a process of receiving and processing an incoming 
document for the system of Fig. 3. Thus, the process begins by receiving a 
document at the network interface (step 400). The parser identifies the 
document type (401) m response to tiie business mterface definition. Using tiie 
business interface definition, which stores a DTD for the document in the XML 
format, the document is parsed (step 402). Next, tiie elements and attributes of 
the document are translated into tiie format of tiie host (step 403). In this 
example, the XML logic structures are translated into JAVA objects which carry 
tiie data of tiie XML element as well as methods associated with the data such 
as get and set functions. Next, tiie host objects are transferred to the host 
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transaction processing front end (step 404). These objects are routed to 
processes in response to the events indicated by the parser and the translator. 
The processes which receive the elements of the document are executed and 
produce an output (step 405). The output is translated to the format of an output 
document as defined by the business interface definition (step 406). In this 
example, the translation proceeds from the form of a JAVA object to that of 
an XML document. Finally, the output document is transmitted to its 
destination through the network interface (step 407). 

Fig. 5 is a more detailed diagram of the event generator/event listener 
mechanism for the system of Fig. 3. In general the approach illustrated in Fig. 5 
is a refinement of the JAVA JDK 1.1 event model. In this model, .three kinds of 
objects are considered. A first kind of object is an event object which contains 
information about the ocburrence of an event. There may be any number of 
kinds of event objects, corresponding to all tiie different kinds of events which 
can occur. A second kind of object is an Event generator, which monitors 
activity and generates event objects when sometiiing happens. Third, event 
listeners, listen for event objects generated by event generators. Event listeners 
generally listen to specific event generators, such as for mouse clicks on a 
particular window. Event listeners call an "ADD event listener" method on the 
event generator. This model can be adapted to the environment of Fig. 3 in 
which the objects are generated in response to parsing and walking a graph of 
objects, such as represented by an XML document 

The system illustrated in Fig. 5 includes a generic XML parser 500. 
Such parser can be implemented using a standard call back model. When a 
parsing event occurs, the parser calls a particular method in an application 
object, passing in the appropriate information in the parameters. Thus a single 
application 501 resides with the parser. The application packages the 
information provided by tiie parser in an XML event object and sends it to as 
many event listeners as have identified themselves, as mdicated by the block 
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502. The set of events 502 is completely parser independent. The events 502 
can be supplied to any number of listeners and any number of threads on any 
number of machines. The events are based on the element structure information 
set ESIS in one alternative. Thus, they consist of a list of the important aspects 
of a document structure, such as the starts and ends of elements, or of the 
recognition of an attribute. XML (and SGML) parsers generally use the ESIS 
structure as a default set of information for a parser to return to its application. 

A specialized ESIS listener 503 is coupled to the set of events 502. This 
Ustener 503 implements the ESIS listener API, and listens for all XML events 
from one or more generators. An element event generator 504 is a specialized 
ESIS listener which is also an XML event generator. Its listeners are objects 
only interested in events for particular types of elements. For example in an 
HTML environment, the listener may only be interested in ordered lists, that is 
only the part of the document between the <0L> and <yOL>tags. For another 
example, a listener may listen for "party .name" elements, or for "service.name" 
elements according to the conunon business language, from the example 
documents above, process the events to ensure that the elements carry data that 
matches the schematic mapping for the element, and react according to the 
process needed at the receivmg node. 

This allows the system to have small objects that listen for particular 
parts of the document, such as one which only adds up prices. Since listeners 
can both add and remove themselves from a generator, there can be a listener 
which only listens to for example the <HEAD> part of an HTML document. 
Because of this and because of the highly recursive nature of XML documents, 
it is possible to write highly targeted code, and to write concurrent listeners. For 
example, an <0L> listener can set up an <LI> listener completely separate from 
the manner in which the <UL> (unordered list) listener sets up its <LI> listener. 
Alternatively, it can create a listener which generates a graphic user interface 
and another which searches a database using the same input. Thus, the 
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document is treated as a program executed by the listeners, as opposed to the 
finished data structure which the application examines one piece at a time. If an 
application is written this way, it is not necessary to have the entire document in 
memory to execute an application. 

The next listener coupled to the set of events 502 is an attribute filter 
505. The attribute filter 505 like the element fiher 504 is an attribute event 
generator according to the ESIS listener model. The listener for an attribute 
filter specifies the attributes it is interested in, and receives events for any 
element having that attribute specified. So for example, a font manager might 
receive events only for elements having a font attribute, such as the <P FONT= 
"Times Roman" /P>. 

The element event generator 504 supplies such element objects to 
specialize the element listeners 504A. 

The attribute event generator 505 supplies the attribute: event objects to 
attribute listeners 505A. Similarly, the attribute objects are supplied to a 
"architecture" in the sense of an SGML/XML transformation from one 
document type to another using attributes. Thus the architecture of 505B allows 
a particular attribute with a particular name to be distinguished. Only elements 
with that attribute defined become part of the output document, and the name of 
the element in the output document is the value of the attribute in the input 
document. For example, if the architecture 505B is HTML, the string: 

<PURCHASES HTML="OL"><ITEM HTML="LI"><NAME 

HTML="B">STUFF<NAME><PRICE 

HTML="B">123<yPRICE></ITEM></PURCHASES> 
translates into: 

<OL><LI><B>STUFF</B><B>123</B><;A.I><OL> 
which is correct HTML. 

The next module which is coupled to the set of events 502 is a tree 

builder 506. The tree builder takes a stream of XML events and generates a tree 
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representation of the underlying document. One preferred version of fhe tree 
builder 506 generates a document object model DOM object 507, according to 
the specification of the W3C (See, http://www.w3.org/TR/1998/ 
WD-DOM- 19980720/ introduction.html). However listeners in event streams 
can be used to handle most requirements, a tree version is useful for supporting 
queries around a document, reordering of nodes, creation of new documents, 
and supporting a data structure in memory from which the same event stream 
can be generated multiple times, for example like parsing the document many 
times. A specialized builder 508 can be coupled to the tree builder 506 in order 
to build special subtrees for parts of the document as suits a particular 
implementation. 

In addition to responses to incoming documents, other sources of XML 
events 502 can be provided. Thus, an event stream 510 is generated by walking 
over a tree of DOM objects and regenerating the original event stream created 
when the document was being parsed. This allows the system to present the 
appearance that the document is being parsed several times. 

The idea of an object which walks a tree and generates a stream of 
events can be generalize beyond the tree of DOM objects, to any tree of objects 
which can be queried. Thus, a JAVA walker 512 may be an application which 
walks a tree of JAVA bean components 513. The walker walks over all the 
publicly accessible fields and methods. The walker keeps track of the objects it 
has already visited to ensure that it doesn't go into an endless cycle. JAVA 
events 514 are the type of events generated by the JAVA walker 5 12. This 
currently includes most of the kinds of information one can derive from an 
object. This is the JAVA equivalent of ESIS and allows the same programming 
approach applied to XML to be applied to JAVA objects generally, although 
particularly to JAVA beans. 

The JAVA to XML event generator 515 constitutes a JAVA listener and 
a JAVA event generator. It receives the stream of events 514 from the JAVA 
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walker 512 and translates selected ones to present a JAVA object as an XML 
document. In the one preferred embodiment, the event generator 5 1 5 exploits 
the JAVA beans API. Each object seen becomes an element, with the element - 
name the same as the class name. Within that element, each embedded method 
5 also becomes an element whose content is the value returned by invoking the 

method. If it is an object or an array of objects, then these are walked in turn. 

Fig. 6 outhnes a particular application built on the framework of Fig. 5. 
This application takes in an XML document 600 and applies it to a 
parser/generator 601. ESIS events 602 are generated and supplied to an 

10 attribute generator 603 and tree builder 604. The attribute generator 

corresponds to the generator 505 of Fig. 5. It supplies the events to the 
"architecture" 505B for translating the XML mput to an HTML output for 
example. These events are processed in parallel as indicated by block 605 and 
processed by listeners. The output of the listeners are supplied to a document 

1 5 writer 506 and then translated back to an XML format for output Thus for 

example this application illustrated in Fig. 6 takes an XML document and 
outputs an HTML document containing a form. The form is then sent to a 
browser, and the result is converted back to XML. For this exercise, the 
architecture concept provides the mapping from XML to HTML. The three 

20 architectures included in Fig. 6 include one for providing the structure of the 

HTML document, such as tables and lists, a second specifying text to be 
displayed, such as labels for input fields on the browser document, and the third 
describes the input fields themselves. The elements of the XML document 
required to mamtain the XML documents structure become invisible fields in 

25 the HTML form. This is usefiil for use in reconstruction of the XML document 

from the mformation the client will put into the HTTP post message that is sent 
back to the server. Each architecture takes the input document and transforms it 
into an architecture based on a subset of HTML. Listeners listening for these 
events, output events for the HTML document, which then go to a document 
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writer object. The document writer object listens to XML events and turns them 
back into an XML document. The document writer object is a listener to all the 
element generators listening to the architectures in this example. 

The organization of the processing module illustrated in Figs. 5 and 6 is 
representative of one embodiment of the parser and transaction process front 
end for the system of Fig. 3. As can be seen, a very flexible interface is 
provided by which diverse transaction processes can be executed in response to 
the incoming XML documents, or other structured document formats. 

Fig. 7 illustrates a node similar to that of Fig. 3, except that it includes a 
business interface definition builder module 700. Thus, the system of Fig. 7 
includes a network interface 701, a document parser 702, and a document 
translator 703. The translator 703 supplies its output to a transaction processing 
front end 704,. which in turn is coupled to listening functions such as 
commercial fimctions 705, a database 706, enterprise functions 707, and other 
generic listeners and processors 708. As illustrated in Fig. 7, the business 
interface definition builder 700 includes a user interface, a conimon business 
library CBL repository, a process for reading coniplementary business interface 
definitions, and a compiler. The user interface is used to assist an enterprise in 
the building of a business interface definition relying on the conunon business 
library repository, and the ability to read complementary business interface 
definitions. Thus, the input document of a complementary business interface 
definition can be specified as the output document of a particular transaction, 
and the output document of the complementary business interface definition can 
be specified as the input to such transaction process. In a similar manner a 
transaction business interface definition can be composed using components 
selected from the CBL repository. The use of the CBL repository encourages 
the use of standardized document formats, such as the example schema (bidl) 
documents above, logical structures and interpretation information in the 
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building of business interface definitions which can be readily adopted by other 
people in the network. 

The business interface definition builder module 700 also includes a 
compiler which is used for generating the translator 703, the objects to be 
5 produced by the translator according to the host transaction processing 

architecture, and to manage the parsing function 702. 

Fig. 8 is a heuristic diagram showing logical structures stored in the 
repository in the business interface definition builder 700. Thus, the repository 
storage representative party business interface definitions 800, including for 

1 0 ' example a consumer BID 801 , a catalog house BID 802, a warehouse BID 803, 
and an auction house BID 804. Thus, a new participant in an online market may 
select as a basic interface description one of the standardized BIDs which best 
matches its business. In addition, the repository will store a set of service 
business interface definitions 805. For example, an order entry BID 806, an 

1 5 order tracking BID 807, an order fulfilhnent BID 808, and a catalog service BID 

809 could be stored. As a new participant in the market builds a business 
interface definition, it may select the business interface definitions of 
standardized services stored in the repository. 

In addition to the party and service BIDs, input and ou^ut document 

20 BIDs are stored in the repository as indicated by the field 810. Thus, a purchase 

order BID 811, an invoice BID 812, a request for quote BID 813, a product 
availability report BID 8 1 4, and an order status BID 8 1 5 might be stored in the 
repository. 

The repository, in addition to the business interface definitions which in 
25 a preferred system are specified as document type definitions according to 

XML, stores interpretation information in the form of semantic maps as 
indicated by the field 816. Thus, semantic maps which are used for specifying 
weights 8 1 7, currencies 8 1 8, sizes 8 1 9, product identifiers 820, and product 
features 821 in this example might be stored in the repository. Further, the 
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interpretation information provides for typing of data structures within the 
logical structures of documents. 

In addition, logical structures used in the composing of business 
interface definitions could be stored in the repository as indicated by block 822. 
Thus, forms for providing address information 823, forms for providmg pricing 
information 824, and forms for providing terms of contractual relationships 
could be provided 825. As the netv^ork expands, the CBL repository will also 
expand and standardize tendmg to make the addition of new participants, and. 
the modification of business interface definitions easier. 

Fig. 9 illustrates the process of building a business mterface definition 
using the system of Fig. 7. The process begins by displaying a BID builder 
graphical interface to the user (step 900). The system accepts user input 
identifying a participant, service and document information generated by the 
graphical interface (step 901). 

Next, any referenced logical structures, interpretation infonnation, 
document definitions and/or service definitions are retrieved from the repository 
in response to user input via the graphical user mterface (step 902). In the next 
step, any complementary business interface definitions or components of 
business interface defmitions are accessed from other participants in the 
network selected via user input, by customized search engines, web browsers or 
otherwise (step 903). A dociunent defmition for the participant is created using 
the information gathered (step 904), The translators for the document to host 
and host to document mappers are created by the compiler (step 905). Host 
architecture data structures corresponding to the definition are created by the 
compiler (step 906), and the business interface definition which has been 
created is posted on the network, such as by posting on a website or otherwise, 
making it accessible to other nodes in the network (step 907). 

Business interface definitions tell potential trading partners the online 
services the company offers and which documents to use to invoke those 
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services. Thus, the services are defined in the business interface definition by 
tiie documents that they accept and produce. This is illustrated in the following 
firagment of an XML service definition. 
<service> 

<service.name>Order Service<servicc.name> 

<service.location>www.veosystem5.com/order</service.location> 
<service.op> 

<service.op.name>SubmitOrder</service.op.nanie> 

<seivice.opJnputdoc>vmw.coinmercc.net/po.dtd</service.op.inputdoc> 
<service.op.outputdoO 

www.veosystenis.com/mvoice.dtd<yservice.op.outputdoO 
</service.op> 

< service.op> 

< service.op.name>Track Order</service.op.name> 
<service.op.inputdo^ www.commerce.net 

/request.track.dtd<service.op.inputdoc> 
<service.op.outputdoO 

www.veosystems.com/response.track,dtd<service.op.outputdoc> 
- </service,op> 
<yservic^ 

This XML fi-agment defines a service consisting of tv^o transactions, one 
for taking orders and the other for tracking them. Each definition expresses a 
contract or promise to carry out a service if a valid request is submitted to the 
specified Web address. The Order service here requires an input docxmient that 
conforms to a standard "po.dtd" Document Type Definition located in the 
repository, v^hich may be local, or stored in an industry wide registry on the 
network. If a node can fulfill the order, it will return a document conforming to 
a customized "invoice.dtd" whose definition is local. In effect, the company is 
promising to do business with anyone who can submit a Purchase Order that 
conforms to the XML specification it declares. No prior arrangement is 
necessary. 
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The DTD is the formal specification or grammar for documents of a 
given type; it describes the elements, their attributes, and the order in which they 
must appear. For example, purchase orders typically contain the names and 
addresses of the buyer and seller, a set of product descriptions, and associated 
terms and conditions such as price and delivery dates. In Electronic Data 
Interchange EDI for example, the X12 850 specification is a commonly used 
model for purchase orders. 

The repository encourages the development of XML document models 
from reusable semantic components that are common to many business 
domains. Such documents can be understood from their common message 
elements, even though they may appear quite different. This is the role of the 
Common Business Library repositoiy. 

The Common Business Library repository consists of information 
models for generic business concepts including: 

• business description primitives like companies, services, and 
products; 

• business forms like catalogs, purchase orders, and invoices; 

• standard measurements, date and time, location, classification 
codes. 

This information is rq^resented as an extensible, public set of XML 
buildmg blocks that companies can customize and assemble to develop XML 
applications quickly. Atomic CBL elements implement industry messaging 
standards and conventions such as standard ISO codes for countries, currencies, 
addresses, and time. Low level CBL semantics have also come from analysis of 
proposed metadata frameworks for Intemet resources, such as Dublin Core. 

The next level of elements use these building blocks to implement the 
basic busmess forms such as those used in XI 2 EDI transactions as well as 
those used in emerging Intemet standards such as OTP (Open Trading Protocol) 
and OBI (Open Buying on the Intemet). 



-50- 



wo 00/23925 PCTAJS99/23426 

CBL's focus is on the functions and information that are common to all 
business domains (business description primitives like companies, services, and 
products; business forms like catalogs, purchase orders, and invoices; standard 
measurements, date and time, location, classification codes). CBL builds on 
5 standards or industry conventions for semantics where possible (e.g., the rules 

that specify "day/month/year" in Europe vs "month/day/year" in the U.S. are 
encoded in separate CBL modules). 

The CBL is a language that is used for designing applications. It is 
designed to bridge the gap between the "document world" of XML and the 

10 "programmmg world" of JAVA or other transaction processing architectures. 

Schema embodies a philosophy of "programmmg with documents" m which a 
detailed formal specification of a document type is the master source jfrom 
which a variety of related forms can be generated. These forms include XML 
DTDs for CBL, JAVA bbjects, programs for converting XML instances to and 

15 from the corresponding JAVA objects, and supporting documentation. 

The CBL creates a single source from which ahnost all of the pieces of a 
system can be automatically generated by a compiler. The CBL works by 
extending SGML/XML, which is normally used to fonnally define the 
structures of particular document types, to include specification of the semantics 

20 associated with each information element and attribute. TTie limited set of 

(mostly) character types in SGML/XML can be extended to declare any kind of 
datatype. 



-51- 



wo 00/23925 



PCT/US99/23426 



Here is a fragment from the CBL definition for the "datetime" module: 
<!— datetime.mod Version: 1.0 ~> 
<!- Copyright 1 998 Veo Systems, Inc. 

<! ELEMENT year (#PCDATA)> 
<! ATTLISTyear 

schema CDATA #FIXED "uni:x-veosystems:stds;iso:8601:3.8'' 

> 

<! ELEMENT month (#PCDATA)> 
<!ATTLIST month 

schema CDATA #FIXED "um:x-veosystems:stds:iso:8601;3.12*' 

> 



In this fragment, the ELEMENT "year" is defined as character data, and 
an associated "schema" attribute, also character data, defmes the schmia for 
"year" to be section 3.8 of the ISO 8601 standard. 

This "datetune" CBL module is in fact defined as an instance of the 
Schema DTD. First, the module name is defined. Then the "datetune" element 
"YEAR" is bound to the semantics of ISO 8601: 

<! DOCTYPE SCHEMA SYSTEM "schema.dtd"> 

<SCHEMA><Hl>Date and Time Module<yHl> 

<ELEMNTTYPE NAME="year" DATATYPE="YEAR'><MODEL> 
<STRING 

DATATYPE="YEAR'></STRING><^ODEL> 
<ATTDEF NAME=:schema;iso8601" DATATYPE=''CDATA"> 
<FIXED>3.8 

Gregorian calendar<yFIXEI><yATTDEF></ELEMENTTYPE> 
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The example market participant and service modules above are also 
stored in the CBL repository. 

In Fig. 10, an Airbill 1000 is being defined by customizing a generic 
purchase order DTD 1 00 1 , adding more specific information about shipping ' 
weight 1002. The generic purchase order 1001 was initially assembled fi-om the 
ground up out of CBL modules for address, date and time, currency, and vendor 
and product description. Using CBL thus significantly speeds the development 
and implementation of XML commerce applications. More importantly, CBL 
makes it easier for commercial applications to be interconnected. 

In the CBL, XML is extended with a schema. The extensions add strong- 
typing to XML elements so that content can be readily validated. For example, 
an element called <CPU_clock_speed> can be defined as an integer with a set 
of valid values: {100, 133, 166, 200, 233, 266 Mhz.}. The schema also adds 
class-subclass hierarchies, so that information can be readily instantiated from 
class definitions. A laptop, for instance, can be described as a computer with 
additional tags for features such as display type and battery life. These and other 
extensions facilitate data entry, as well as automated translations between XML 
and traditional Object-Oriented and relational data models. 

Thus the completed BID is run through the compiler which produces the 
DTDs for the actual instance of a participant and a service as outlined above, the 
JAVA beans \sdiich correspond to the logical structures in the DTD instances, 
and transformation code for transforming fi-om XML to JAVA and firom JAVA 
to XML. In alternative systems documentation is also generated for display on a 
user mterface or for printing by a user to facilitate use of the objects. 

For the example market participant and service DTDs set forth above, 
the JAVA beans generated by the compiler are set forth (with some redactions 
for conciseness) as follows: 
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import com.veo.vsp.doclet.meta.Document; 
public class AddressPhysical extends Document { 

public static final String DOC^TYPE = "address.physical"; 
String mStreet; 
5 String mCity; 

public final static int AK = 0; 
public fmal static int AL = 1 ; 
public final static int AR = 2; 
public fmal static int AZ ~ 3; 
1 0 public fmal static int CA » 4; 



public final static int WI = 48; 
public final static int WV = 49; 
15 public fmal static int WY = 50; 

intmState; 

String mPostcode; 
public final static int AD - 51; 
public final static int AE = 52; 
20 public final static int AF = 53; 

public final static int AG = 54; 
public final static int AI = 55; 
public final static int AM = 56; 

25 

int mCountiy; 
public AddressPhysicalOi 

super(DOC_TYPE); 
mStreet = new StringQ;. 
30 mCity = new StringQ; 

this.mState = -l; 
mPostcode « null; 

this.mCountry = -1; 

} 

35 public AddressPhysical(String doc_type){ 
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super(doc_type); 
mSti^et new StringQ; 
mCity = new StringQ; 

this.inState = -l; 
mPostcode = null; 

this.mCountiy = -1; 

} 

static public AddressPhysical initAddressPhysical(String iStreet,String iCity,int 
iState,String iPostcode.int iCountry){ 

AddressPhysical obj = new AddrcssPhysicalQ; 
obj.initializeAll(iStreet, iCity, iState, iPostcpde, iCountry); 
return obj; 

} 

public void initiaiizeAll(String iStreet, String iCity,int iState,String iPostcode,int 
iCountry){ 

mStreet = iStreet; 
mCity = iCity; 
mState = iState; 
mPostcode = iPostcode; 
mCountry = iCountry; 

} 

public String getStreetO{ 
return mStreet; 

} 

public String getStreetToXMLO{ 

if (getStreetO = null) return null; 
char [] c = getStreet().toCharArray(); 
StringBufFer sb = new StringBufferQ; 
for (int X = 0; X < c.length; x-H-){ 

switch(c[x]){ 

case '>': 

sb.appendC>"); 
break; 
case '<': 
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sb.^pendC*<"); 
break; 
case*&-: 

sb.append("&"); 
break; 
case 

sb.appendC'""); 
break; 
case V: 

sb.append("""); 
break; 
default: 

if (Character.isDefined(c[x])) 
sb.append(c[x]); 

} ■ 

} 

return sb.toStringQ; 

} 

public void setStreet(String inp){ 
this.inStreet = inp; 

} 

public void streetFromXML(String n){ 
setStreet(n); 

} 

public String getCityQI 
return mCity; 

} 

public String getCityToXMLO{ 

if (getCityO = null) return null; 
char [] c = getCity().toCharArrayO; 
StringBuffer sb = new StringBufferQ; 
for (int X = 0; X < c.length; x4-f ){ 
switch(c[x]){ 
case^': 

sb.append(">"); 
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break; 
case •<•: 

sb.append("<-); 
break; 

5 case '&': 

sb.append("&"); 
break; 
case "": 
sb.append("""); 
10 break; 

case T: 

sb.append{"""); 
break; 
default: 

15 if(Character.isDefmed(c[x])) 

sb.append(c[x]); 

} 

} 

return sb.toStringO; 

20 } 

public void setCity(String inp){ 
this.mCity = inp; 

} 

public void cityFroiiiXML(String n){ 
25 setCity(n); 
} 

public mtgetStateO{ 
return mState; 

} 

30 public String getStateToXML(){ 

switch (mState){ 

case AK: return "AK"; 

case AL: return "AL"; 

case AR: return "AR"; 
35 case AZ: return "AZ"; 
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} 

return null; . 

} 

public void setState(int inp){ 
this.mState = inp; 

} 

public void stateFromXML(String s){ 

if (s.equals("AK")) mState = AK; 
else if (s.cquals("AL"))mState = AL; 
else if (s.equals("AR"))mState = AR; 
else if (s.equals("AZ"))mState = AZ; 

} 

public String getPostcodeQi 
return mPostcode; 

} 

public String getPostcodeToXMLO{ 

if (getPostcodeO = null) return null; 
char [] c = getPostcode().toCharArrayO; 
StringBuffer sb = new StringBufferO; 
for (int X = 0; X < c.length; x-H-){ 

switch(c[x]){ 

case •>': 

sb.append(">"); 
break; 
case '<*: 

sb.append("&It;"); 
break; 
case '&': 

sb.append("&"); 
break; 
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sb.append("""); 

break; 
case X: 

sb.append("""); 

break; 
default: 

if (Character.isDefined(c[x])) 
sb.append(c[x]); 

} 

} 

return sb.toStringQ; 

} 

public void setPostcode{String inp){ 
thisjnPostcode = inp; 

} 

public void postcodeFromXML(String n){ 
setPostcode(n); 

} 

public int getCountryO{ 
return mCountry; 

} 

public String getCountryToXMLO{ 
switch (mCountry) { 

case AD: return "AD"; 
case AE: return "AE"; 
case AF: return "AF"; 

} 

return null; 

} 

public void setCountry(int inp){ 
this.mCountry = inp; 

} 

public void countryFromXML(String s){ 
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10 



if (s.equals("AD")) mCountry = AD; 
else if (s.equals("AE"))mCountry = AE; 
else if {s.equalsi("AF"))mCoimtry = AF; 
else if (s.equals("AG"))mCountTy = AG; 
else if (s.equals("AI"))mCoiintry = AI; 



} 

} 

package com.veo.xdk.dev.schema.test.blib; 



import com.veo.vsp.doclet.meta.Document; 
public class AddressSet extends Document { 
1 5 public static final String DOC^TYPE "address.set"; 

AddressPhysical mAddressPhysical; 
String [] mlelephone; 
String D mPax; 
String n mEmail; 
20 String [] mintemet; 

public AddressSetO{ 

super(DOC_TYPB); 

this.mAddressPhysicaI = new AddressPhysicalQ; 
mTelephone = null; 
25 mFax - null; 

mEmail = null; 
mintemet = null; 
} 

public AddressSet(String doc_type}{ 
30 super(doc_type); 

this.mAddressPhysical = new AddressPhysicalQ; 

mTelephone ~ null; 

mFax = null; 

mEmail = null; 
35 mintemet = null; 
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} 

static public AddressSet initAddressSet(AddressPhysical iAddressPhysical,String [] 
iTelephone,String [] iFax,String Q iEmail,String [] ilntemet){ 
AddressSet obj = new AddressSetO; 

obj.initializeAlKiAddressPhysical, iTelephone, iFax, iEmail, ilntemet); 
return obj; 

) 

public void initializeAIl(AddressPhysical iAddressPhysical,String [] iTelephone,String 
□ iFax,String □ iEmail,String [] ilntemet){ 

mAddressPhysical = iAddressPhysical; 
mTelephone = iTelephone; 
mFax = iFax; 
mEmail = iEmail; 
mintemet = ilntemet; 

} 

public AddressPhysical getAddressPhysical(){ 
return mAddressPhysical; 

} 

public void setAddressPhysical(AddressPhysical inp){ 
tfais.mAddressPhysical inp; 

} 

public String [] getTelephoneO{ 
return mTelephone; 

} 

public String getTelephone(int index){ 
if (this.mTeiephone = null) . 
return null; , 

if (index >= this.mTelephone.length) 
return null; 

if (index < 0 && -index > this.mTelephone.length) 
return null; 

if (index >= 0) return this.mTelephone[index]; 

return this.mTeIephone[this.mTelephone.length + index]; 

} 
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public String □ getTelephoneToXMLQi 
String Q valArr = getTelephoneQ; 
if (valAiT = null) return null; 
String n nvArr = new String[valAir.lengA]; 
for (int z = 0; z < nvArr.length; z-h-){ 
char [] c = vaIArr[z].toCharArrayO; 
StringBuffer st = new StringBufferQ; 
StringBuffer sb = new StringBufferQ; 
for (int X = 0; X < c.length; x++) { 

switch(c[x]){ 

case >*: 

sb.append(">"); 
break; 
case '<*: 

sb.appen<j{"<"); 
break; 
case 

sb.append("&"); 
break; 
case 

sb.append("""); 
break; 
case 

sb.append("""); 
break; 
de&ult: 

if (Character.isDefined(c[x])) 
sb.append(c[x]); 

} 

} 

nvArr[z] = sb.toStringQ; 
} 

return nv Arr; 

} 

public void setTelephone(int index, String inp){ 
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if (this.mTelephone = null) { 
if (index <0) { 

this.mTelephone = new String[l]; 
this.mTeiephone[0] = inp; 
} else { 

this,mTelephone = new String[index + !]; 
this.mTelephone[index] = inp; 

} 

} else if (index <0){ 

String [] newTelephone = new String[this.mTelephone.length + 1]; 
java.lang.System.arraycopy((Object)mTelephone, 0, 
(Object)newTelephone, 0, this.mTelephone.length); 

newTelephone[newTelephone.length - 1] = inp; 
mTelephone = newTelephone; 
} else if (index >= this.mTelephone.length) { 

String n newTelephone = new Strmg[index + 1 ]; 

java.lang.Systeni.arraycopy((Object)mTelephorie, 0, 
(Object)newTelephone, 0, this.mTelephone.length); 

newTelephone[index] = inp; 
mTelephone = newTelephone; 

}else{ 

this.mTelephone[index] = inp; 

} 

) 

public void setTelephone(String [] inp){ 
this.mTelephone = inp; 

} 

public void telephoneFromXML(String n){ 
setTelephone(-l, n); 

} 

public String [] getFaxO{ 
return mFax; 

) 

public String getFax(int index){ 
if (this.mFax = null) 
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return null; 

if (index >= this.mFax.length) 

return null; 
if (index < 0 && -index > this.mFaxJength) 

return null; 
if (index >= 0) return this.mFax [index]; 
return this.mFax[this.mFax.length + index]; 

} 

public String Q getFaxToXMLO{ 
String [] valArr = getPaxO; 
if (valArr = null) return null; 
String [] nvArr = new String[valArr.length]; 
for (int 2 0; z < nvArr.length; 2-h-){ 
char [] c = valAn[z].toCharArray(); 
StringBuffer st = new StringBufferQ; 
StringBufTer sb = new StringBufferQ; 
for (int x = 0; X < c.length; x-h-){ 

switch(c[x]){ 

case'>': 

sb.append(">"); 
break; 
case '<': 

sb.append("<"); 
break; 
case 

sb.append("&"); 
break; 
case 

sb.append(""**); 

break; 
case"': 

sb.append("""); 

break; 
deMlt: ' 

if (Character.isDefined(c[x])) 
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sb.append(c[x]); 

} 

} 

nvAiT[z] = sb.toStringO; 
5 } . 

return nvAir; 

} 

public void setFax(int index. String inp){ 
if(this.mFax = null){ 
10 if(index<0){ 

this.mFax = new Stnng[l]; 
this,mFax[0]= inp; 
} else { 

this.mFax = new String[index + 1]; 
15 this.mFaxpndex] = inp; 

} 

} else if (index <0){ 

String [] newFax = new String[this.mFax,length + 1 ]; 
java.lang.System.arraycopy((Object)mFax, 0, (Object)newFax, 0, 

20 this.mFax.lengdi); 

newFax[newFax.Iength - 1] = inp; 
mFax = newFax; 
} else if (index >= this,mFax. length) { 

String [] newFax = new String[index +1]; 
25 java.lang.System.arraycopy((Object)mFax, 0, (Object)newFax, 0, 

this.mFax.lengdi); 

newFax[index] = inp; 
mFax = newFax; 

} else { 

30 this.mFax[index] = inp; 

} 

} 

public void setFax(String D inp){ 
this.mFax = inp; 

35 } 
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public void faxFromXML(Strlng n){ 
setFax(-l,n); 

} 

public String [] getEmailO{ 
return mEmail; 

} 

public String getEmail(int index) { 
if (this.mEinail = null) 
return null; 

if (index >= this.mEmail.length) 
return null; 

if (index < 0 && -index > this.mEmail.length) 

return null; 
if (index >= 0) return this.mEmail[index]; 
return this.mEmail[this.mEmail.length + index]; 

} 

public String Q getEmailToXMLQi 
String [] valAiT = getEmailQ; 
if (valAiT = null) return null; 
String n nvArr = new String[valArr. length]; 
for (int z = 0; z < nvArr.length; z-H-){ 
char □ c = valArr[z].toCharArrayO; 
StringBuffer st = new StringBufferQ; 
StringBuffer sb = new StringBufferQ; 
for (int x = 0; x < c.length; x-h-){ 

switeh(c[x]){ 

case*>': 

sb.append(">**); . 
break; 
case 

sb.append("&It;"); 
break; 
case 

sb.append("&"); 
break; 
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sb.append("""); 
break; 
case "': 

sb.append(""");. 
break; 
default: 
if (Character.isDefined(c[x])) 
sb.append(c[x]); 

} 

} 

nvArr[2] ^ sb.toStringO; 
} 

return nvArr; 

} 

public void setEmail(int index. String inp){ 
if (this.m£inai] = null) { 
if(index<0){ 
this.m£mail = new String[l]; 
this.mEmai][0] = inp; 
} else { 

this.mEmaiI = new String[index + 1]; 
this.mEmail[index] = inp; 

} 

} elseif(mdex<0) { 

String □ newEmail = new String[this.ni£mail.length +1]; 
java,lang.System.arraycopy((Object)mEmail, 0, (Object)newEmail, 

0, this.mEmail.Iength); 

newEmail[newEmail.length - 1] = inp; 
mEmail = newEmail; 
} else if (index >= this.mEmaiLlength){ 

String [] newEmail = new String[index + 1]; 
java.lang.System.arraycopy((Object)mEmail, 0, (Object)newEmail, 

0, this.mEmai].length); 

newEmail[index] = inp; 
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mEmail = newEmail; 

} else { 

thisjnEmail[index] inp; 

} 

} 

public void setEmail(String [] mp){ 
this.niEmail = inp; 

} 

public void emailFromXML(String n){ 
setEmail(-l,n); 

} 

public String Q getlntemet0{ 
return mintemet; 

} 

public String getlnternet(int index){ 
if (this.nilntemet null) 
return null; 

if (index >= this.mlntemet.lengdi) 

return null; ^ 
if (index < 0 && -index > this.nilntemetlengdi) 

return null; 
if (index >= 0) return this.mlntemet[index]; 
return this.mlntemet[this,mlntemet.length + index]; 

} 

public String Q getIntemetToXMLO{ 

String □ valArr = getlntemetO; 
if (valArr = null) return null; 
String [] nvArr = new String[valArr.length]; 
for (int z = 0; z < nvArr.length; z++){ 
char Q c = valArr[z].toCharAiTayO; 
StringBuffer st = new StringBuffer(); 
StringBuffer sb = new StringBufferQ; 
for (int x = 0; X < c.lengtii; x++){ 

switch(c[x]){ 

case •>': 
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sb.append(">"); 
break; 
case '<: 

sb.append("<"); 
break; 
case 

sb,append("&"); 
break; 
case"": 

sb.append("""); 
break; 
case 

sb.append("""); 
break; 
default: 

if (Character.isDefmed(c[x])) 
sb.append(c[x]); 

} 

} 

nvArr[z] = sb.toStringO; 
} 

return nvArr; 

} 

public void setlntemet(int index, String tnp){ 
if (this.mlntemet = null) { 
if(index<0){ 

this.mlntemet = new String[l]; 
this.mlntemet[0] = inp; 
} else { 

this.mlntemet = new String[index + 1]; 
this.mlnteniet[index] = inp; 

} 

} else if (index <0) { 

String [] newlntemet = new String[this.mlntemet.length + 1]; 
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java.lang.System.arraycopy((Obj€Ct)mIntemet, 0, 
(Object)newIntemet, 0, thkmlntemetlength); 

newlntemet[newlntemet.length - 1] = inp; 

mintemet = newlntemet; 
} else if (index >= this.mlntemetlength){ 

String □ newlntemet = new String[index + 1]; 

java.lang.Systeni.arraycopy((Object)mIntemet, 0, 
(Object)newIntemet, 0, this.mlntemet.length); 

new]ntemet[index] = inp; 

mintemet = newlntemet; 

} else { 

this.mlntemet[index] - inp; 

} 

} 

public void setIntemet(String [] inp){ 
this.nrilntemet = inp; 

} 

public void intemetFromXML(String n){ 
setlntemet(-l, n); 

} 

} 

package com.veo.xdk.dev.schema.test.blib; 

import com,veo.vsp,doclet.nfieta.Document; 
public class Business extends Party { 

public static final String DOC_TYPE = "business"; 

String aBusinessNumber; 

public BusinessO{ 

superpOC^TYPE); 

aBusinessNumber = new StringQ; 

} 

public Business(String docjype){ 

super(doc_type); 
aBusinessNumber = new StringQ; 
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} 

static public Business initBusiness(String iBusinessNumber,String [] 
iPartyNainejAddressSet iAddFessSet){ 

Business obj = new BusinessQ; 
5 obj.initializeAlKiBusinessNumber, iPartyName, iAddressSet); 

return obj; 

} 

public void initializeAll(String iBusinessNumber,String [] iPartyName,AddressSet 
10 iAddressSet){ 

aBusinessNumber = iBusinessNumber; 
super.inttializeAlI(iPartyName, iAddressSet); 

} 

public String getBusinessNumberO{ 
IS return aBusinessNumber; 

} 

public String getBusinessNumberToXMLO{ 

if (getBusinessNumber() = null) return null; 
char n c = getBusinessKumberQ-toCharArrayO; 
20 StringBufTer sb = new StringBufferQ; 

for (int X = 0; X < clength; x++){ 
switch(c[x]){ 
case •>': 

sb.append(">"); 
25 break; 

case 

sb.append("<"); 
break; 
case '&': 

30 sb.append("&"); 

break; 
case 

sb,append("""); 
break; 

35 case T: 
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sb.append("""); 
break; 
default: 
if (Character.isDefined(c[x])) 
sb.append(c[x]); 

} 

} 

return sb.toStringO; 

} 

public void setBusinessNumber(String inp){ 
this.aBusinessNumber = inp; 

} 

public void businessNumberFromXML(String n){ 
setBusinessNuinber(n); 

} , 

} 

import com.veo.vsp.doclet.ineta.Document; 
public class Party extends Document { 

public static final String DOC_TYPE = "party"; 
String [] mPartyName; 
AddressSet mAddressSet; 
public PartyO{ 

super(DOC_TYPE); 
mPartyName new String[0]; 

this jnAddressSet = new AddressSetQ; 

} 

public Party(String doc_type){ 

super(doc_type); 
mPartyName = new String[0]; 

this.mAddressSet = new AddressSetQ; 

} 

static public Party initParty(String [] iPartyName,AddressSet iAddressSet){ 
Party obj = new PartyQ; 
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obj.initializeAll{iPartyName, iAddressSet); 
return obj; 

} 

public void initializeAllCString [] iPartyName,AddressSet iAddressSet){ 
mPartyName = iPartyName; 
mAddressSet = iAddressSet; 

} 

public String [] getPartyNameO {. 
return mPartyName; 

} 

public String getPartyName(int index){ 
if (this.mPartyName = null) 
return null; 

if (index >= this.mPartyName. length) 
return null; 

if (index < 0 && -index > this.mPartyName.length) ? 
return null; 

if (index >= 0) return this,mPartyName[index]; 

return this,mPartyName[this jnPartyName.length + index]; 

} 

public String [] getPartyNameToXMLQ { 
String [] valArr = getPartyName(); 
if (valArr = null) return null; 
String D nvArr ^ new String[valArr.length]; 
for (int z = 0; 2 < nvArr.length; zH-){ 
char [] c = valArr[z].toCharArrayO; 
StringBuffer st = new StringBufferQ; 
StringBuffer sb = new StringBufferQ; 
for (int x = 0; x < clength; x++){ 

switch(c[x]){ 

case*>*: 

sb.append(">"); 
break; 
case 
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sb.append("&It;"); 
break; 
case 

sb.append("&"); 
break; 
case 

sb.append("""); 
break; 
case 

sb.append("""); 

break; 
default: 

if (Character.isDefiiied(c[x])) 
sb.appeDd(c[x]); 
} ; 

} 

nvArr[z] = sb.toStringQ; 
} 

return nvArr; 

} 

public void setPartyName(int index, String mp){ 
if (this.mPartyName = null) { 
if (index <0){ 

this.mPartyName = new String[ 1]; 
this.mPartyName[0] = inp; 
} else { 

this.inPartyName = new String[index + 1]; 
this.mPartyName[index] = inp; 

} 

} else if (index <0) { 

String [] newPartyName = new String[this,niPartyName.length + 1 ]; 
java.lang.System.arraycopy((Object)mPartyName, 0, 
(Object)newPartyName, 0, this.mPartyName.length); 

newPartyName[newPaityName.length - 1] = inp; 
mPartyName = newPartyName; 
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} else if (index >= this.mPaityNanie.length) { 

String [] newPartyName = new String[index + 1 ]; 
java.!ang.System.arraycopy({Object)mPartyName, 0, 
(Object)newPartyName, 0, this.mPartyNanie.Iength); 

newPartyName[index] = inp; 
mPartyName = newPartyName; 

} else { 

this.mPartyName[index] = inp; 

} 

} 

public void setPartyName(String [] inp){ 
this.mPartyName = inp; 

} 

public void partyNanieFromXML(String n){ 
setPartyName(- 1 , n); 

} 

public AddressSet getAddressSetO{ 
return mAddressSet; 

} 

public void setAddressSet(AddressSet inp){ 
this.mAddressSet = inp; 

} 

} 



package com.veojcdk.dev.schema.test.blib; 

import com.veo.vsp.docletmeta.Document; 
public class Person extends Party { 

public static final String DOC^TYPE = "person"; 

String aSSN; 

public PersonO{ 

super(DOC_TYPE); 

aSSN = null; 

} 

public Person(String doc Jype){ 
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super(doc_type); 
:vvaSSN = null; 
} 

static public Person initPeTSon(String iSSN,String [] iPartyName,AddressSet 
5 iAddressSet){ 

Person obj = new PersonQ; 

obj. initialize All(iSSN, iPartyName, iAddressSet); 

return pbj; 

} 

10 

public void initializeAll(String iSSN.String [] iPartyName,AddressSet iAddressSet){ 
aSSN = iSSN; 

super.initializeAlI(iPartyName, iAddressSet); 

} 

15 public String getSSN(){ 

return aSSN; 

} . ^ 
public String getSSNToXMLQl 

if (getSSNQ = null) return null; 
20 charOc^getSSNO.toCharArrayO; 

StringBufFer sb = new StringBufFerQ; 
for (int X = 0; X < c.length; x++){ 

switch(c[x]){ 

case *>': 

25 sb.append(">"); 

break; 
case •<•: 

sb.append("<"); 
break; 

30 case'&': 

sb.append("&"); 

break; 
case "": 

sb.appendC*""); 
35 break; 
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case T: 

sb.append("""); 
break; 
default: 
if (Character.isDefmed(c[x])) 
sb.append(c[x]); 

} 

} 

return sb.toStringO; 

} 

public void setSSN(String inp){ 
tfais.aSSN = inp; 

} 

public void sSNFromXML(String n){ 
setSSN(n); 

} 

} 

package com.veo.xdk.dev.scheina.testblib; 

import com.veo.vsp.doclet.meta.Document; 
public class PrototypeService extends Document { 

public static final String DOC_TYPE = "prototype.service"; 
String mServiceName; 
String □ mServiceTerms; 
String [] mServiceLocation; 
ServiceOperation [] mServiceOperation; 
public PrototypeServiceO{ 

super(DOC_TYPE); 
mServiceName = new StringQ; 
mServiceTerms = new String[0]; 
mServiceLocation = new String[0]; 

tfais.mServiceOperation = new ServiceOperation[0]; 

} 

public PrototypeService(String doc_type){ 
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super(doc__type); 
mServiceName - new StringQ; 
mServiceTerms = new Strmg[0]; 
mServiceLocation = new String[0]; 
5 this.mServiceOperation = new ServiceOperation[0]; 

} 

static public PrototypeService initPrototypeService(String iServiceName,String n 
iServiceTenns,String [] iServiceLocation,ServiceOperation [] iServiceOperation){ 
PrototypeService obj = jiew PrototypeServiceQ; 
10 obj.initializeAlKiServiceName, iServiceTenns, iServiceLocation, 

iServiceOperation); 

return obj; 

} 

1 5 public void initiaIizeAll(String iServiceName, String Q iServiceTenns,String [\ 

iServiceLocation,ServiceOperation [] iServiceOperation) { 

mServiceName = iServiceName; ' 
mServiceTerms = iServiceTerms; 
mServiceLocation = iServiceLocation; 
20 mServiceOperation = iServiceOperation; 

} 

public String getServiceNaraeO{ 
return mServiceName; 

} 

25 public String getServiceNameToXMLQ { 

if (getServiceNameO = null) return null; 
char D c = getServiceNameO-toCharArrayO; 
StringBuffer sb - new StringBufferO; 
for (int X = 0; X < c.length; x++){ 
30 switch(c[x]){ 

case >*: 
sb.append(">"); 
break; 
case '<*: 

35 sb.append("<"); 
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break; 
case 

sb.append("&ainp;"); 
break; 
case"": 

sb.append("""); 
break; 
case T: 

sb.appendC'""); . 
break; . 
default: 

if (Character.isl>efined(c[x])) 
sb.append(c[x]); 

} 

} 

return sb.toStringO; 

} 

public void 5etServiceName(String inp){ 
this.mServiceNaine = inp; 

} 

public void serviceNaineFromXML(String n){ 
setServiceName(n); 

} 

public String Q getServiceTennsO{ 
return mServiceTerms; 

} 

public String getServiceTenns(int index){ 
if (this.mServiceTenns = null) 
return null; 

if (index >= this.mServiceTerms.Iength) 
return null; 

if (index < 0 && -index > thisjnServiceTerms.length) 
return null; 

if (index >= 0) return this.mServiceTerms[index]; 

return Ais.mServiceTerms[this.mServiceTerms.length + index]; 
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} 

public String [] getServiceTermsToXMLO{ 
String n valArr = getServiceTermsQ; 
if (valArr = null) return null; 
String [] nvArr = new String[valArr.length]; 
for (int z = 0; z < nvArr.Iength; z-H-){ 
char [] c =^ valArr[2].toCharArrayO; 
StringBuffer st « new StringBufferQ; 
StringBuffer sb = new StringBuffer(); 
for (int X = 0; X < c.length; x++){ 

switch(c[x]){ 

case *>': 

sb.append(">"); 
break; 
case 

sb.append("<"); 
break; 
case '&': 

sb.append("&"); 
break; 
case "": 

sb.append("4""); 
break; 
case "': 

sb.append(""'0; 
break; 
default: 

if (Character.isDefmed(c[x])) 
sb.append(c[x]); 

} 

} 

nvAir[z] = sb.toStringO; 
} 

return nvArr; 
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public void setServiceTerms(int index. String inp){ 
if (this jnServiceTerms = null) { 
if (index <0){ 

this.mServiceTemis = new String[l]; 
this.mServiceTerms[0] = inp; 
} else { 

this.mServiceTenns = new String[index + 1]; 
this.mServiceTerms[index] = inp; 

} 

} else if (index <0) { 

String [] newServiceTems = new String[this.mServiceTerms.length 

+ 1]; 

java.lang.System.aiTaycopy((Object)mServiceTenns, 0, 
(Object)newServiceTenns, 0, this.mServiceTerms.length); 

new5erviceTerms[newServiceTerms.length - 1] = inp; 
mServiceTenns = newServiceTeims; 
} else if (index >= this.mServiceTenns.Iength){ ;? 

String [] newServiceTems = new String[index + 1]; 
java.lang.System.aiTaycopy((Object)mServiceTenns, 0, 
(Object)newServiceTerms, 0, this.mServiceTerms.length); 

newServiceTerms[index] = inp; 
mServiceTerms = newServiceTerms; 

} else { 

this.mServiceTerms[index] = inp; 

} 

} 

public void setServiceTerms(String Q inp){ 
tfais.mServiceTenns = iiip; 

} 

public void serviceTermsFromXML(String n){ 
setServiceTenns(-l, n); 

} 

public String [] getServiceLocationO{ 
return mServiceLocation; 

} 
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public String getServiceLocation(int index){ 
if (this.mServiceLocation = null) 
return null; 

if (index >= this jnServiceLocation.length) 
5 return null; 

if (index < 0 && -index > this.mServiceLocation.length) 
return null; 

if (index 0) return this.mServiceLocation[index]; 

return this.mServiceLocation[this.mServiceLocation.length + index]; 

10 } 

public String Q getServiceLocationToXMLO{ 

String □ valArr = getServiceLocationQ; 

if (valArr = null) return null; 

String [] nvArr = new String[valArr. length]; 
15 for (int z = 0; z < nvArr.iength; z-f+){ 

char [] c = valArr[z].toCharArrayO; 

StringBuffer st = new StringBuflfcrO; ' 

StringBufifer sb = new StringBufferQ; 

for (int x = 0; x < clength; x-H-){ 
20 switch(c[xl){ 

case •>': 

sb.append(">"); 
break; 
case*<: 

25 sb.append("<"); 

break; 
case '&'; 

sb.append("&"); . 
break; 

30 case 

sb.append("""); 
break; 
case"*: 

sb.append("""); 
35 break; 
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de&ult: 

if (Character.isDefmed(c[xi)) 
sb.sq)pend(c[x]); 

} 

} 

nvArr[z] = sb.toStringQ; 
} 

return nvArr; 

} 

public void setServiceLocation(int index. String inp){ 
if (this.mServiceLocation = null) { 
if (index <0){ 

this.mServiceLocation = new String[l]; 
this.mServiceLocation[0] = inp; 
} else { 

this.mServiceLocation = new String[index + 1]; 
this.niServiceLocation[index] = inp; 

} 

} else if (index <0){ 

String n newServiccLocation = new 
String[this.mServiceLocation. length + ]]; 

java.lang.System,aTTaycopy((Object)mServiceLocation, 0, 
(Object)newServiceLocation, 0, this.mServiceLocation.length); 

newServiceLocation[newServiceLocation.length - 1] = inp; 

mServiceLocation = newServiceLocation; 
} else if (index >» this.mServiceLocation.lengtfa){ 

String 0 newServiceLocation = new String[index + 1]; 

java.lang.System.arraycopy((Object)mServiceLocation, 0, 
(Object)newServiceLocation, 0, this.mServiceLocation.length); 

newServiceLocation[index] = inp; 

mServiceLocation = newServiceLocation; 

} else { 

thisjnServiceLocation[index] = inp; 

} 
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public void setServiceLocation(String Q inp){ 
this.mServiceLocation = inp; 

} 

public void serviceLocationFromXML(String n){ 
setServiceLocation(-l, n); 

} 

public ServiceOperation [] getServiceOperationO{ 
return mServiceOperation; 
} . 
public ServiceOperation getServiceOperation(int index){ 
if (this.mServiceOperation = null) 
return null; 

if (index >= this.mServiceOperation.length) 
return null; 

if (index < 0 && -index > this.mServiceOperatiQn.length) 
return null; 

if (index >= 0) return this.mServiceOperation[index]; " 

return this.mServiceOperation[tfiis.mServiceOperation.length + index]; 

} 

public void setServiceOperation(int index, ServiceOperation inp){ 
if (this.mServiceOperation = null) { 
if(index<0){ 

this.mServiceOperation = new ServiceOperation[l]; 
this.mServiceOperation[0] = inp; 
}else{ ^ 
this.mServiceOperation = new ServiceOperation[index + 1]; 
this.mServlceOperation[index] = inp; 

} 

} else if (index < 0) { 

ServiceOperation [] newServiceOperation = new 
ServiceOperation[this.mServiceOperation.length + I]; 

java.lang.System.arraycopy((Object)mServiceOperation,0, 
(Object)newServiceOperation, 0, this.mServiceOperation.length); 

newServiceOperation[newServiceOperation,length - 1] = inp; 
mServiceOperation = newServiceOperation; 
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} eJse if (index >= this.inServiceOperation.Iength){ 

ServiceOperation Q newServiceOperation ~ new 
ServiceOperation[index + 1]; 

javaJang.System.arraycopy((Object)mServiceC)peration,0, 
(Object)newServiceOperation, 0, this.mServiceOperation.length); 

newServiceOperation [index] = inp; 
mServiceOperation = newServiceOperation; 

} else { 

this.mServiceOperation[index] = inp; 

} 

} 

public void setServiceOperation(ServiceOperation [] inp){ 
this^mServiceOperation = inp; 

} 

} 

package com.veo.xdk.dev.schema.testblib; 

import com.veo.vsp.doclet.meta.Document; 
public class Service extends Document { 

public static final String DOC__TYPE = "service"; 
String mServiceName; 
String mServiceLocation; 
ServiceOperation [] mServiceOperation; 
String mServiceTeims; 
public ServiceO{ 

super(DOC_TYPE); 
mServiceName = new StringQ; 
mServiceLocation = new StringQ; 

this.mServiceOperation - new ServiceOperation[0]; 
mServiceTerms = new StringQ; 
} 

public Service(String doc_type){ 

super(doc_type); 
mServiceName = new StringQ; 
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mServiceLocation = new StringQ; 

tiiis.inServiceOperation = new ServiceOperation[0]; 
mServiceTerms = new StringQ; 
} 

static public Service initService(String iServiceName,String 
iServiceLocation,ServiceOperation [] iServiceOperation,String iServiceTerms){ 
Service obj = new ServiceQ; 

obj.initiaIi2eAll(iServiceName, iServiceLocation, iServiceOperation, 

iServiceTerms); 

return obj; 

} 

public void initialize A lI(String iServiceName,String 
iServiceLocation,ServiceOperation [] iServiceOperation,String iServiceTerms){ 
mServiceName = iServiceName; 
mServiceLocation = iServiceLocation; 
mServiceOperation = iServiceOperation; . 
mServiceTerms = iServiceTenns; 

} 

public String getServiceNameQf 
return mServiceName; 

} 

public String getServiceNameToXML(){ 

if (getServiceNameO = null) rettim null; 
char □ c = getServiceNameO-toCharArrayO; 
StringBuffer sb = new StringBuf&rO; 
for (int X = 0; X < c.Iength; x-H-){ 

switch(c[x]){ 

case *>*: 

sb.append(">"); 
break; 
case 

sb.appendr<"); 
break; 
case 
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sb.append("&"); 
break; 
case "": 

sb.append("""); 
break; 
case V: 

sb.append("""); 
break; 
de&ult: 

if (Character.isDefmed(c[x])) 
sb.append(c[x]); 

} 

} 

return sb.toStringO; 
} ' ; 

public void setServiceName(String inp){ 

tfais.mServiceName = inp; . 

} 

public void serviceNameFromXML(String n){ 
setServiceName(n); 

} 

public String getServiceLocationO{ 
return mServiceLocation; 

} 

public String getServiceLocationToXMLO{ 

if (getServiceLocationO = null) return null; 
char [] c = getServiceLocationO-toCharAirayO; 
StringBufFer sb - new StringBufferQ; 
for (int X = 0; X < c.length; x-H-){ 
switch(c[x]){ 
case •>': 
sb.append(">"); 
break; 
case*<': 

sb.appendC'<"); 
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break; 
case*&*: 

sb.append("&"); 
break; 
case 

sb.append("""); 
break; 
case V: 

sb.append('*""};. 
break; 
default: 
if (Character.isDefmed(c[x])) 
sb.append(c[x]); 

} 

} ] 

return sb.toStringO; 
} ^ ' 

public void setServiceLocation(String mp){ 

this.mServiceLocation - inp; 

} 

public void serviceLocationFromXML(String n){ 
setServiceLocation(n); 

} 

public ServiceOperation [] getServiceOperationO{ 
return mServiceOperation; 

} 

public ServiceOperation getServiceOperation(int index){ 
if (this.mServiceOperation = null) 
return null; 

if (index >= this.niServiceOperation.length) 
return null; 

if (index < 0 && -index > this.mServiceOperation.length) 
return null; 

if (index >= 0) return this.mServiceOperation[index]; 

return this.mServiceOperation[this.mServiceOperation.length + index]; 
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} 

public void setServiceOperation(int index, ServiceOpeiation inp){ 
if (thisjnServiceOperation = null) { 
if (index <0){ 

this.mServiceOperation new ServiceOperation[l]; 
this.mServiceOperation[0] = inp; 
} else { 

this.mServiceOperation = new ServiceOperation[index + 1]; 
thi5.mServiceOperation[index] = inp; 

} 

} else if (index <0) { 

ServiceOperation [] newServiceOperation = new 
ServiceOperation[this,mServiceOperation.length +1]; 

java.lang.System.arraycopy((Object)mServiceOperation, 0, 
(Object)newServiceOperation, 0, this.mServiceOperation.length); 

newServiceOperation[newServiceOperationaength - 1] = inp; 

mServiceOperation = newServiceOperation; 
} else if (index >= this.mServiceOperation.length){ 

ServiceOperation Q newServiceOperation = new 
ServiceOperation[index + 1]; 

java.lang.System.arraycopy((Object)mServiceOperation, 0, 
(Object)newServiceOperation, 0, this.mServiceOperation.length); 

newService6peration[index] = inp; 
mServiceOperation = newServiceOperation; 

} else { 

this.mServiceOperation[index] - inp; 

} 

} 

public void setServiceOperation(ServiceOperation Q inp){ 
this.mServiceOperation = inp; 

} 

public String getServiceTermsO{ 
return mServiceTeims; 

} 

public String getServiceTennsToXML(){ 
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if (getServiceTermsQ = null) return null; 
char [] c = getServiceTermsO-toCharAirayO; 
StringBufFer sb = new StringBufferQ; 
for (int X = 0; X < c.Iength; x-h-){ 

switch(c[x]){ 

case'>*: 

sb.append("&gtr); 

break; 
case '<: 

sb.append("<"); 

break; 
case '&': 

sb,append("&ainp;"); . 

break; 
case 

sb,append("""); 
break; 
case T: 

sb.append{"""); 
break; 
default: 
if (Character. isDefined{c[x])) 
sb.append(c[x]); 

} 

} 

return sb.toStringO; 

} 

public void setServiceTerms(Strlng inp){ 
this.raServiceTerms = inp; 

} 

public void serviceTennsFromXML(String n){ 
setServiceTenns(n); 

} 

} 
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package coin.veo.xdk.dev.schema.testbltb; 

import coin.veo.vsp.doclet.meta.Docunient; 
public class ServiceOperation extends Document { 
5 public static final String DOC^TYPE = "service.operation"; 

String mServiceOperationName; 
String mServiceOperationLocation; 
String mServiceOperationlnput; 
String mServiceOperationOutput; 
10 public ServiceOperationO{ 

super(DOC_TYPE); 
mServiceOperationName = new StringQ; 
mServiceOperationLocation = new StringQ; 
mServiceOperationlnput = new StringQ; 
1 5 mServiceOperationOutput = new StringQ; 

} . 
public ServiceOperation(String doc^type) { 

super(doc_type); 
mServiceOperationName = new StringQ; 
20 mServiceOperationLocation = new StringQ; 

mServiceOperationlnput ^ new StringQ; 
mServiceOperationOutput = new StringQ; 
} 

static public ServiceOperation initScrviceOperation(String 
25 iServiceOperationName,String iServiceOperationLocation,String iServiceOperationInput,String 

iServiceOperationOutput){ 

ServiceOperation obj - new ServiceOperationQ; 

obj.initializeAll(iServiceOperationName,iServiceOperationLocation, 
iServiceOperationlnput, iServiceOperationOutput); 
30 return obj; 

} 

public void initializeAll(String iServiceOperationName,String 
iServiceOperationLocation,String iServiceOperationlnput,String iServiceOperationOu^}ut){ 
35 mServiceOperationName = iServiceOperationName; 
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mServiceOperationLocation = iServiceOperationLocation; 
mServiceOperationlnput = iServiceOperationlnput; 
mServiceOperationOu^ut = iServiceOperationOutput; 

} 

5 public String getServiceOperationNameO { 

return mServiceOperationName; 

} 

public String getServiceOperationNameToXMLQ { 

if (getServiceOperationNameO = null) return null; 
1 0 char Q c = getServiceOperationNatneO.toChar ArrayQ; 

StringBufFer sb = new StringBufferQ; 
for (int X = 0; X < clength; x++){ 
switch(c[x]){ 
case *>': 

15 sb.append(">"); 

break; 
case '<•: 

sb.append("<"); 
break; 

20 case*&': 

sb.append("&"); 
break; 
case "": 

sb.append("""); 
25 break; 

case V: 

sb.append("""); 
break; 
default: 

30 if (Chararter.isDefmed(c[x])) 

sb.append(c[x]); 

} 

} 

return sb.toStringQ; 

35 } 
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public void setServiceOperationName(String inp) { 
ftis.mServiceOperationNanie ~ inp; 

} 

public void serviceOperationNameFromXML(String n){ 
5 setServiceOperationName(n); 
} 

public String getServiceOperationLocation(){ 
return mServiceOperationLocation; 

} 

10 public String getServiceOperationLocationToXML(){ 

if (getServiceOperationLocationO = null) return null; 

char [] c = getServiceOperationLocationO.toCharArrayO; 

StringBuffer sb = new StringBufferO; 

for (int X = 0; X < c.length; x-H-){ 
15 switch(c[x]){ 

case •>': 

sb.append(">"); . 
break; 
case '<■: 

20 sb.append("<"); 

break; 
case 

sb.append("&"); 
break; 

25 case"": 

sb.append("""); 
break; 
case ^": 

sb.append("""); 
30 break; 

default: 

if (Character.isDefined(c[x])) 
sb.append(c[x]); 

} 

35 } 
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return sb.toStringQ; 

} 

public void setServiceOperationLocation(String iiip){ 
this.mServiceOperationLocation - inp; 

} 

public void serviceOperationLocationFromXML(String n){ 
setServiceOperationLocation(n); 

} 

public String getServiceOperationInputO{ 
return mServiceOperationlnput; 

} 

public String getServiceOperationInputToXML0{ 

if (getServiceOperationlnputO = null) return null; 
char [] c = getServiceOperationlnputO-toCharAirayO; 
StringBuffer sb = new StringBufferQ; 
for (int X = 0; X < cJength; x++){ 

switch(c[x]){ 

case •>•: 

sb.append(">"); 
break; 
case 

sb.append("<"); 
break; 
case 

sb.append("&"); 
break; 
case 

sb.appendC^""); 
break; 
case V: 

sb.append("""); 
break; 
default: 

if (Character.isDefmed(c[x])) 
sb.append(c[x]); 
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} 

} 

return sb.toStringO; 

} 

5 public void setServiceOperationInput(String inp){ 

this,mServiceOperationInput = inp; 

} 

public void serviceOperationInputFromXML(String n) { 
setServiceOperationInput(n); 

10 } 

public String getServiceOperationOutputO{ 
return mServiceOperationOutput; 

} 

public String getServiceOperationOutputToXMLQ { 
15 if (getServiceOperationOutputO = null) return null; 

char [] c = getServiceOperationOutputQ.toCharArrayO; 
StringBuffer sb = new StringBuffer(); 
for (int X = 0; X < c.length; x+t){ 
switch(c[x]){ 
20 case'>': 

sb.append(">"); 
break; 
case '<*: 

sb.appendr<"); 
25 break; 

case 

sb.append("&"); 
break; 
case"":. 

30 sb,append("""); 

break; 
case r : 

sb,append("""); 
break; 

35 default: 
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if (Character.isDefined(c[x])) 
sb.append(c[x]); 

} 

} 

S return sb.toStringO; 

} 

public void setServiceOperationOutput(String inp){ 
this.mServiceOperationOutput ~ inp; 

} 

10 public void serviceOperationOutputFromXML(String n){ 

setServiceOperationOutput(n); 

} 



IS package com.veo.xdk.dev.schema.test.blib; 

import com.veo.vsp.doclet.meta.Document; 
public class ServiceSet extends Document { 

public static fmal String DOC_TYPE = "service.set"; 
20 Service [] mService; 

public ServiceSetO{ 

super(DOC_TYPE); 
this.mService = new Service[0]; 

} 

25 public ServiceSet(String doc_type){ 

5uper(doc_type); 
this.mService - new Service[0]; 

} 

static public ServiceSet initServiceSet(Service [] iService){ 
30 ServiceSet obj = new ServiceSetQ; 

obj.initializeAIl(iService); 
return obj; 

} 

35 public void initializeAll(Service [] iService){ 
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mService ^ iService; 

} 

public Service [] getServiceO{ 
return mService; 

} 

public Service getService(int index) { 
if (this.mService = null) 
return null; 

if (index >= tfais.mService.length) 
return null; 

if (index < 0 && -index > this.mService.lengtii) 

return null; 
if (index >= 0) return this.mService[index]; 
return this.mService[this.mService.length + index]; 

} 

public void setService(int index. Service inp){ 
if (this.mService = null) { 
if(index<0){ 

this.mService = new Service[l]; 
this.mService[0] - inp; 
} else { 

this.mService = new Service[index + 1]; 
this.mService[index] = inp; 

} 

} else if (index <0){ 

Service Q newService = new Service[this.mService.length + 1]; 
java.lang.System.arraycopy((Object)mService, 0, 
(Object)newService, 0, this.mService.Iength); 

newService[newService.length - 1] = inp; 
mService = newService; 
} else if (index >= this.mService.length){ 

Service 0 newService = new Service[index + 1]; 

java.lang.System.arraycopy((Object)mService.O, 
(Object)newService, 0, this.mService.Iength); 

newService[index] = inp; 
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mService = newService; 

}else{ 

this.mService[mdex] = inp; 

} 

} 

public void setService(Service [] inp){ 
this.raS€rvice = inp; 

} 

} 

In addition to the JAVA beans set fortti above, transformation code is 
produced for translating from JAVA to XML and XML to JAVA as set forth 
below: 

JavatoXML 

<!DOCTYPE tree SYSTEM "tree.dtd''> 
<tree source = "null" pass-through = "false"> 
<before> 

<vardef name = "attribute.def *> 

<element source = "ATTRIBUTE" class = "NAME" type = "5" position = "-2"> 
<^arse> 

<data class = "java.lang,String" position ^ "-2"/i> 
<;^arse> 
</elemenC> 
<yvardef> 

<vardef name = "pcdata.der> 

<element source = "PCDATA" class = "NAME" type = "4" position = "-2"> 
<parse> 

<data class = "999" type = "6" position = "-2"/> 
</parse> 
</elenient> 
<Vvardef> 

<vardef name = "contentdef > 
<element source = "PCDATA"> 
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<parse> 

<data class = "999" type = "6" position = '•-2"/> 
</parse> 
<yelement> 
</vardef> 

<vardef name = "ServiceSetvar"> 

<element source = "com.veo.xdk.dev.schema.test.blib.ServiceSet" class = "serviccset" type = 
"4" position = ".2**> 
<parse> 

<callvar name = "Service. var"/> 
</parse> 
</element> 
</vardef> 

<vardef name - "PrototypeService.var"> 

<element source = "com.veo.xdk.dev.schema.test.blib.PrototypeService" class = 
"prototypcservice" type =^ "4" position = •'-2"> 
<parse> 

<cal!varname = "pcdata.def' parms = "setSource ServiceNameToXML setGenerator 
service.nanie"A> 

<callvar name = "pcdata.def ' panns = "setSource ServiceTermstoXML setGenerator 

service.tenns"/> 

<callvar name = "pcdata.def ' parms == "setSource ServiceLocationToXML setGenerator 
service.location"/> 

<callvar name = "ServiceOperation.var"/^ 
</parse> 
</elemenP^ 
</vardef> 

<vardef name = "Service, var"> 

<element source = "com.veo.xdk.dev.schema.testblib.Service" class = "service" type = "8" 
position = "0"> 
<parse> 

<ca!lvar name = "pcdata.def ' parms = "setSource ServiceNameToXML setGenerator 
service.name"/> 

<callvar name = "pcdata.def ' paims = "setSource ServiceLocationToXML setGenerator 
service.location"/> 
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<callvar name = "ServiceOperation.var"/> 

<callvar name = "pcdata.der pajrms = "setSource ServiceTermsToXML setGenerator 
service.tenns"/i> 

</parse> 
</element> 
</vardef> 

<vardef name - "ServiceOperation.var"> 

<element source = "com.veo.xdk.dev.schema.test.blib.ServiceOperation" class = 
*'service.operation*' type = "4" position = "-2"> 
<parse> 

<callvar name = "pcdata.def ' panns = "setSource ServiceOperationNameToXML 
setGenerator service.operation,name"/i>. 

<callvar name = "pcdata.def ' parms = "setSource ServiceOperationLocationToXML 
setGenerator service.operation. location"/> 

<callvar name = "pcdata.def ' parms = "setSource ServiceOperationlnputToXML 
setGenerator service.operation.input"/> 

<calivar name = "pcdata.der parms = "setSource ServiceOperationOutputToXML 
setGenerator service.operation.output"A> 
</parse> 
</element> 
</vardef> 
<;/before> 
<parse> 

<cailvar name = "ServiceSet.var"/i> 
<talJvar name = "PrototypeService.var"/> 
<tallvar name = "Service. var"/> 
<callvarname - "ServiceOperation.var"/> 
<^arse> 
</tree> 

XML to Java 

<!DOCTYPE tree SYSTEM "tree.dtd"> 
<tree source = "null" pass-through = "fake"> 
<before> 
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<vardef name = **business.var"> 
<element source = "business" 

class = "com.veojcdk.dev.schematest.blib.Business" 
type = "7" setter = "setBusiness'*> 
<before> 

<onattribute name = "busmess.number"> 
. <actions> 

<callmeth name = "businessNumberFromXML"> 
<panns> 

<^etattr name = "business.number**A> 
</pannS> 
<callmeth> 
</actions> 
</onattribute> 
</before> 
<parse> 

<calivar name = "party.name.var" parms = "setPosition -!"/> 
<callvar name = "address.set.var"A> 
</parse> 
</eIement> 
</vardef> 

<vardef name = "party .name.var*^ 

<element source «= "party.name" setter - "partyNameFromXML" position = class = 
"java.lang.String"> 
<i)arse> 

<data class = "java.lang.Stnng" position = "0"A> 
</parse> 
</elemen1> 
</vardef^ 

<vardef name = "city.var"> 

<element source = "city" setter = "cityFromXML" position = "-1" class = "java.Iang.String"> 
<parse> 

<data class = "java.lang.String" position = "0"/i> 
<^arse> 
</element> 
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'^varde^ 

<vardef name = "internet. var"> 

<element source = "internet" setter = "intemetFromXML" position = class = 
"java.lang.String"> 
<parse> 

«iata class = "java.lang.String" position = "0"/i> 
</parse> 
<;/element> 
</wBrdef> 

<vardef name = "countiy,var"> 

<element source "country" setter "countryFromXML" position = "-1" class = 
"java.lang,String"> 
<parse> 

<data class = "java.lang.String" position = "0"/> 
<Vparse> : 
</eiement> 
</vardct> 

<vardef name = "state.var"> 

<element source = "state" setter = "stateFromXML" position = "-1" class = "java.lang.Slring"> 
<parse> 

<data class = "java.lang.String" position = "0"/> 
</parse> 
</element> 
</vardef> 

<vardef nmne = "emaiLvar"> 

<element source = "email" setter = "emailFromXML" position = "-1" class = 
"java.lang.String"> 
<parse> 

<data class = "java.lang.String" position = "0"/i> 
</parse> 
<;/element> 
</ywrdef> 

<vardef name = "address.physical.var"> 
<element source = "address.physical" 

class = "com.veo.xdk.dev.schema.test.blib.AddressPhysical" 
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type = "7" setter = "setAddressPhysical"> 
<before> 
<before> 
<parse> 

5 <callvar name = "streetvar" parms = ^etPosition -1 "A> 

<callvar name = "city.var" panns = "setPosition -!"/> 
<callvar name = "state.var" parms = "setPosition -l"/> 
<callvar name = "postcode.var" parms === "setPosition - 1 "/i> 
<Callvar name - "country. var" parms .= "setPosition -!**/> 
10 </paxsO 
</elemen1> 
</vardeC> 

<vardef name = "telephone.var'*> 

<e}ement source = "telephone" setter = "telephoneFromXML" position = "-1" class = 
15 "java.lang.String"> 
<parse> 

<data class = "java.Iang.String" position = "0"^ 
</^arse> 
<element> 
20 </vardef> 

<vardef name = "person, var"> 
<element source = "person" 

class = "com.veo.xdk.dev.schema,test.blib.Person" 
type = "7" setter = "setPerson"> 
25 <before> 

<dnattribute name = "SSN"> 
<actions> 

<callmeth name = "sSNFromXML"> 
<parms> 

30 <getattr name = "SSN"> 

</parms> 
</caIlmeth> 
</actions> 
</onattribute> 
35 <;/before> 
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<parse> 

<callvar name = "party .name.var" parms = "setPosition -1 "/> 
<tiallvar name = "address.setvar"/> 

</parse> 
</elemenP' 
</vardef> 

<vardef name = "fax.var"> 

<element source = "fex" setter = "fexFromXML" position = "-1 " class = "java.lang.String"> 
<parse> 

<data class = "javaJang.String" position = "0"/> 
</parse> 
</element> 
</vardef> 

<vardef name = "street. var"> 

<element source = "street" setter = "streetFromXML" position = "-1" class = 
"java.lang.String**> 
<parse> 

<data class = "java.lang.String" position = "0"^ 
<yparse> 
</element> 
<yvardef> 

<vardef name = "address.setvar"> 



<element source = "address.set" 

class = "com.veo.xdk.dev.schema.testbUb.AddressSet" 
type = "7" setter = "setAddressSet"> 



<before> 




<Vbefore> 




<parse> 




<callvar name = 


"address.physical.var"/> 


<cailvarname = 


"telephone, var" parms = "setPosition -l"yi> 


<Callvarname = 


"fax.var" panns = "setPosition -!"/> 


<callvar name = 


"emailvar" parms = "setPosition -1"^ 


<calivarname = 


"internet, var" parms « "setPosition -1"A> 


</parse> 





</elemcnt> 
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<yvardef> 

<vardef name = "postcode. var'*> 

<element source = "postcode" setter - **postcodeFromXML" position = 1 " class = 
"java.lang.String'> 
5 <parse> 

<data class - "java.lang.String" position = "0"/> 
</parse> 
</element> 
</vardeC> 

1 0 <vardef name = "market participant.var'*> 

<element source = "market,participant". 

class - "com.veo.xdk.dev.schema;testblib.MarketParticipant" 
type-"?" position = "0"> 
<before> 

15 </before> - 

<parse> 

<callvar name - "business. var"/> 
<callvar name = "person.var"/> 
</pars6> 
20 </element> 
</vardef> 
</before> 
<parse> 

<callvar name = "business.var"/i> 
25 <callvar name = "party.name.var"/> 

<callvar name = "city.var"/i> 

<callvar name = "intemetvar"/> 

<callvar name = "country .var"/i> 

<callvar name = "state.var"/> 
30 <callvar name = "email.var"/> 

<callvar name = "address.physical.var"/i> 

<tallvar name = "telephone.var"/> 

<callvar name = "person. var"/> 

<callvar name = "fax.var"/> 
3 5 <callvar name = "street var"/> 
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<callvar name = "address.setvar"/> 
<caUvar name - "postcode.var"/> 
<callvar name = "market.paiticipant.var"/> 

</parse> 
<ytree> 

Makefiles: 

# this makefile was generated by bic version 0.0. 05/02/1998 
# 

# 
# 

# get the package name from the package argument passed to SchemaGen 
PACKAGE^NAME = com/veo/xdk/dev/schema/test/blib 

JAVA_SOURCES += \ 
MarketParticipantjava \ 
Business.java\ 
Person Java \ 
Party .Java \ 

AddressPhysical.java \ 
AddressSetJava \ 

MAKEFILE_MASTER_DIR = xxx 

include $(MAKEFILE_MASTER_DIR)/Makefile.master 

all:: $(JAVA_CLASSES) 

# 

# this makefile was generated by bic version 0.0. 05/02/1998 
# 
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# 
# 

5 # get the package name from the package argument passed to SchemaGen 

PACKAGE_NAME = com/veo/xdk/dev/schema/test/blib 

JAVA^SOURCES +== \ 
ServiceSetjava \ 
1 0 PrototypeService.java \ 

Service.java\ 
ServiceOperationJava \ 

MAKEFILE_MASTER_DIR = xxx 
1 5 include $(MAKEFILE_MASTER_DIR)/Makefile.master 

all:: $(JAVA_CLASSES) 

Finally, the XML document instances generated at run time according to 
20 the model above for one example follows: 

<!DOCTYPE market.participant SYSTEM "maricetparticipantdtd" > 
<market.pa]ticipant> 

25 <business business.number=** 1234567890** > 

<party.name>IBM</party.name> 

<address.set> 
30 <addres5.physical> 

<street>l IBM Way</street> 
<city>Palo Alt(><Vcity> 
<state>CA<ystate> 
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<postcode>94304<ypostcode> 

<country>USA</country> 

<;/address.physica> 

<telephone>123 456-7890</teiephone> 
<fax>123 456 0987<yfax> 
<emaiI>ibinec@ibm.com</emai!> 
<yaddress.set> , 

</business> 

<;/market.participant> 

<!DOCTYPE service SYSTEM "service,dtd" > 

<service.set> 

<service> 

<service.name>Order Service</service.name> 
<seiviceJocation>wwwabmxom/order<yserviceJocation> 

<service.operation> 

<service.operation.name>SubmitOrder<yservice.operation.name> 
<service.operationJocation>wwjbmxom/order/submit</service.location> 
<servicexperation.input>um:x-ibm:semces:order:operations:po.dtd<^^ 
<;service.operation,output>um:x- 

ibm;services:order:operations:poack.dtd</service.operation.output> 
<yservice.operation> 

<service.operation> 

<service.operation.name>Track Order</service.operation.name> 

<servicexperationJocation>wwJbmxoni/order/track<;/seiviceJocation 
<service.operation.inpuP>um:x- 

ibm:seivices:order:operations:trackJrequest.dtd<;/seivicexperation.inpu^ 
<&ervice.operation.ou^ut>iini:x- 

ibm:seivices:order:operations:trackJresponse.dtd</servicexperationxutp^^ 
</service.operation> 



-108- 



W600/23W5 



PCTAJS99/23426 



</service> 
•^yserviccseP- 

Using the tools along with a BID composer application, which provides 
a drag, drop and forms editing user interface, a developer is able to create a 
business interface definition and to produce a well formed, valid business 
interface definition in the form of an XML document. Thus, the example run 
time instance is a business interface defmition for an ordering service for IBM 
to be used by Ingram Micro and others to order laptop computers from IBM. 
(There is no relationship between the applicant and IBM or Ingram Micro). 
Utilizing these processes, a user is able to build a system that allows for 
programming of a business interface using the documents defined according to 
the present invention. 

The role of CBL and the BID processor of the present invention in an 
XML/JAVA environment can be fiirther understood by the following 
explanation of the processing of a Purchase Order. 

Company A defines its Purchase Order document type using a visual 
programming environment that contains a library of CBL DTDs and modules, 
all defined using conmion business language elements so that they contain data 
type and other interpretation information. Company A's PO might just involve 
minor customizations to a more generic "transaction document" specification 
that comes with the CBL library, or it might be built from the ground up from 
CBL modules for address, date and time, currency, etc. 

The documentation for the generic "transaction document" specification 
(such as the transactdtd set out above) typifies the manner in which CBL 
specifications are built from modules and are interlinked with other CBL DTDs. 

A compiler takes the purchase order defmition and generates several 
different target forms. All of these target forms can be derived through "tree to 
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tree" transformations of the original specification. The most unportant for this 
example are: 

(a) the XML DTD for the purchase order. 

(b) a JAVA Bean that encapsulates the data structures for a purchase 
order (the JAVA classes, arguments, datatypes, methods, and 
exception structures are created that correspond to information in 
the Schema definition of the purchase order). 

(c) A "marshaling" program that converts purchase orders that 
conform to the Purchase Order DTD into a Purchase Order 
JAVA Bean or loads them into a database, or creates HTML (or 
an XSL style sheet) for displaymg purchase orders in a browser. 

(d) An "unmarshaling" program that extracts the data values from 
Purchase Order JAVA Beans and converts them into an XML 
document that conforms to the Purchase Order DTD. 

Now, back to the scenario. A purchasing application generates a 
Purchase Order that conforms to the DTD specified as the service interface for a 
supplier who accepts purchase orders. 

The parser uses the purchase order DTD to decompose the purchase 
order instance into a stream of information about the elements and attribute 
values it contains. These "property sets" are then transformed into 
corresponding JAVA event objects by wrapping them with JAVA code. This 
transformation in effect treats the pieces of marked-up XML document as 
instructions in a custom programming language whose grammar is defined by 
the DTD. These JAVA events can now be processed by the marshaling 
applications generated by the compiler to "load" JAVA Bean data structures. 
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Turning the XML document into a set of events for JAVA applications 
to process, is unlike the normal model of parsing in which the parser output is 
mamtained as an internal data structure and processing does not begin until 
parsing completes. The event based processing, in response to the BID 
definitions, is the key to enabling the much richer functionality of the processor 
because it allows concurrent document application processing to begin as soon 
as the first event is emitted. 

JAVA programs that "listen for" events of various types are generated 
from the Schema definition of those events. These listeners are programs 
created to carry out the business logic associated with the XML definitions in 
the CBL; for example, associated with an "address" element may be code that 
validates the postal code by checking a database. These listeners "subscribe" to 
events by registering with the document router, which directs the relevant events 
to all the isubscribers who are mterested in them. 

This publish and subscribe architecture means that new listener 
programs can be added without knowledge by or impact on existing ones. Each 
listener has a queue into which the router directs its events, which enables 
multiple listeners can handle events in parallel at their own pace. 

For the example purchase order here, there might be listeners for: 

• the purchase order, which would connect it to an order entry 
program, 

• product descriptions, which might check inventory, 

• address information, which could check Fed Ex or other service 
for delivery availability, 

buyer information, which could check order history (for 
creditworthiness, or to offer a promotion, or similar processing 
based on knowing who the customer is). 
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Complex listeners can be created as configurations of primitive ones 
(e.g., a purchase order listener may contain and invoke these listeners here, or 
they may be invoked on their own). 

Fig. 1 1 illustrates the market maker node in the network of Fig. 1 . The 
5 market maker node includes the basic structures of the system of Fig. 3, 

including a network interface 1101, a document parser 1 1 02, a document to host 
and hoist to document translator 1 1 03, and a fi-ont end 1 1 04, referred to as a 
router in this example. The market maker module 1 105 in this example 
includes a set of business interface definitions, or other identifiers sufficient to 

1 0 support the market maker function, for participants in the market, a CBL 

repository, and a compiler all serving the participants in the market. The router 
1 104 includes a participant registry and document filters which respond to the 
events generated at the output of the translator and by the parser to route 
incoming docimients according to the participant registry and according to the 

1 5 element and attribute filters amongst the listeners to the XML event generators. 

Thus, certain participants in the market may register to receive documents that 
meet prespecified parameters. For example, input documents according to a 
particular DTD, and including an attribute such as numbers of products to be 
purchased greater than a threshold, or such as a maximum price of a docimient 

20 request to be purchased, can be used to filter documents at the router 1 1 04. 

Only such documents as match the information registered in the participant 
registry at the router 11 04 are then passed on to the registered participant. 

The router 1 104 may also serve local host services 1 105 and 1 106, and 
as such act as a participant in the market as well as the market maker. 

25 Typically, documents that are received by the router 1 1 04 are traversed to 

determine the destinations to which such documents should be routed, there 
again passed back through the translator 1 103, if necessary, and out the network 
interface 1 101 to the respective destinations. 
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The market maker is a server that binds together a set of internal and 
e3Ctemal business services to create a virtual enterprise or trading community. 
The server parses incoming documents and invokes the appropriate services by, 
for example, handing off a request for product data to a catalog server or 
5 forwarding a purchase order to an ERP system. The server also handles 

translation tasks, mapping the information from a company ' s XML documents 
onto document formats used by trading partners and into data formats required 
by its legacy systems. 

With respect to the service definition above, when a company submits a 

10 purchase order, the XML parser in the server uses the purchase order DTD to 

transform the purchase order instance into a stream of information events. These 
events are then routed to any application that is programmed to handle events of 
a given type; in some cases, the information is forwarded over the Internet to a 
different business entu-ely. In the purchase order example, sevearal applications 

1 5 may act on information commg from the parser: 

• An order entry program processes the purchase order as a 
complete message; 

• An ERP system checks inventory for the products described in 
the purchase order; 

20 • A customer database verifies or updates the customer's address; 

• A shipping company uses the address information to schedule a 
delivery 

• A bank uses the credit card information to authorize the 
transaction. 

25 Trading partners need only agree on the structure, content, and 

sequencing of the bxisiness documents they exchange, not on the details of APIs. 
How a document is processed and what actions result is strictly up to the 
business providing the service. This elevates integration from the system level 
to the business level. It enables a busmess to present a clean and stable interface 
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to its business partners despite changes in its internal technology 
implementation, organization, or processes. 

Figs. 12, 13 and 14 illustrate processes executed at a market maker node 
in the system of Fig. 1 1. In Fig. 12, an input document is received at the 
network interface from an originating participant node (step 1200). The 
document is parsed (step 1201). The document is translated to the format of the 
host, for example XML to JAVA (step 1202). The host formatted events and 
objects are then passed to the router service (step 1203). The services registered 
to accept the document according to the document type and content of the 
document are identified (step 1204), The document or a portion of the 
document is passed to the identified services (step 1205). As service is 
performed in response to the document content (step 1206). The output data of 
the service is produced (step 1207). The output is converted to the document 
format, for example from a JAVA format to an XML format (step 1208). 
Finally, the output document is sent to a participant node (step 1209). 

The registration service is one such fimction which is managed by the 
router. Thus, a market participant document is accepted at the network interface 
as shown m Fig. 13 (step 1300). The market participant document is stored in 
the busmess mterface definition repository (step 1301) for the market maker 
node. In addition, the document is parsed (step 1302). The parsed document is 
translated into the format of the host (step 1303). Next, the document is passed 
to the router service (step 1304). The router service includes a listener which 
identifies the registration service as the destination of the document according to 
the document type and content (step 1305). The document or elements of the 
document are passed to the registration service (step 1306). In the registration 
service, the needed service specifications are retrieved according to the business 
interface definition (step 1307). If the service specifications are gathered, at 
step 1308, the router service filters are set according to the business interface 
definition and the service specifications (step 1309). Registration 
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acknowledgment data is produced (1310). The registration acknowledgment 
data is converted to a document format (step 1311). Finally, the 
acknowledgment document is sent to the participant node indicating to the 
participant that is successfully registered with the market maker (step 1312). 

The process at step 1307 of gathering needed service specifications is 
illustrated for one example in Fig. 14. This process begins by locating a service 
business interface definition supported by the market participant (step 1400). 
The service definition is retrieved, for example by an E-mail transaction or web 
access to repository node (step 1401). The service specification is stored in the 
BID repository (step 1402). The service business interface definition document 
is parsed (step 1403). The parsed document is translated into the format of the 
host (step 1404). Host objects are passed to the router service (step 1405). The 
registration service is identified according to the document type and content 
(step 1406). Finally, the information in the service business interface definition 
document is passed to the registration service (step 1407) for use according to 
the process of Fig. 13. 

Fig. 15 illustrates the processor, components and sequence of processing 
of incoming data at market maker node according to the present invention. The 
market maker node includes a communication agent 1500 at the network 
interface. The communication agent is coupled with an XML parser 1501 
which supplies events to an XML processor 1 502. The XML processor supplies 
events to a document router. The document router feeds a document service 
1504 that provides an interface for supplying the received documents to the 
enterprise solution software 1505 in the host system. The communication agent 
1500 is an Internet interface which includes appropriate protocol stacks 
supporting such protocols as HTTP, SMTP, FTP, or other protocols. Thus, the 
incoming data could come in an XML syntax, an ASCII data syntax or other 
syntax as suits a particular communication channel. All the documents received 
in non-XML syntaxes are translated into XML and passed the XML parser. A 
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translation table 1506 is used to support the translation from non-XML form 
into XML form. 

The converted documents are supplied to the parser 1501. The XML 
parser parses the received XML document according to the document type 
definition which matches it. If an error is foimd, then the parser sends the 
document back to the communication agent 1500, A business interface 
definition compiler BIDC 1507 acts as a compiler for business interface 
definition data. The DTD file for the XML parser, JAVA beans corresponding 
to the DTD file, and translation rules for translating DTD files to JAVA beans 
are created by compiling the BID data. An XML instance is translated to JAVA 
instance by referring to these tools. Thus the BID compiler 1507 stores the 
DTD docxmients 1508 and produces JAVA dociiments which correspond 1509. 
The XML documents are passed to the processor 1502 which translates them 
into the JAVA format. In a preferred system, JAVA documents which have the 
same status as the document type definitions received in the XML format are 
produced. The JAVA beans are passed to the document router 1503. The 
document router 1503 receives the JAVA beans and passes the received class to 
the appropriate document service using a registry program, for example using 
the event listener architecture described above. The document service 1504 
which receives the document in the form of JAVA beans from the router 1503 
acts as the interface to the enterprise solution software. This includes a registry 
service 15 1 0 by which listeners to XML events are coupled with the incoming 
data streams, and a service manager 1 5 11 to manage the routing of the incoming 
documents to the appropriate services. The document service manager 1511 
provides for administration of the registry service and for maintaining document 
consistency and the like. 

The document service communicates with the back end system using any 
proprietary API, or using such more common forms as the CORB A/COM 
interface or other architectures. 



-116- 



wo 00/23925 



PCT/US99y23426 



Fig. 1 6 provides a heuristic diagram of the market maker and market 
participant structures according to the present invention. Thus, the electronic 
commerce market according to the present invention can be logically organized 
as set forth in Fig. 16. At the top of the organization, a market maker node 1600 
is established. The market maker node includes resources that establish a 
marketplace 1601. Such resources mclude a market registry service and the 
like. Businesses 1602 register in the marketplace 1601 by publishing a business 
interface definition. The business interface definition defines the services 1603 
for commercial transactions in which the businesses will participate. The 
transactions 1604 and services 1603 use documents 1605 to define the inputs 
and outputs, and outline the commercial relationship between participants in the 
transaction. The documents have content 1606 which carries the particulars of 
each transaction. The mariner in which the content is processed by the 
participants in the market, and by the market maker is completely independent 
of the document based electronic commerce network which is established 
according to the present invention. Overall, a robust, scalable, mtuitive 
structure is presented for enablmg electronic commerce on communication 
networks is provided. 

Thus, the present invention in an exemplary system provides a platform 
based on the XML processor and uses XML documents as the mterface between 
loosely coupled business systems. The documents are transferred between 
businesses and processed by participant nodes before entering the company 
business system. Thus the platform enables electronic commerce applications 
between businesses where each business system operates using different mtemal 
commerce platforms, processes and semantics, by specifying a common set of 
business documents and forms. 

According to the present invention, virtual enterprises are created by 
interconnecting business systems and service, are primarily defined in terms of 
the documents (XML-encoded) that busmesses accept and generate: 
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• "if you send me a request for a catalog, I will send you a catalog: 

• "if you send me a purchase order and I can accept it, I will send 
you an invoice". 

The foregoing description of a preferred embodiment of the invention 
5 has been presented for purposes of illustration and description. It is not 

intended to be exhaustive or to limit the invention to the precise forms 
disclosed. Obviously, many modifications and variations will be apparent to 
practitioners skilled in this art. It is intended that the scope of the invention be 
defined by the following claims and their equivalents. 
10 What is claimed is: 
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CLAIMS 

1 . An interface for transactions among nodes in a network 
including a plurality of nodes which execute processes involved in the 
transactions, comprising: 

a machine readable specification of an interface to transaction processes 
stored in memory accessible by at least one node in the network, including 
interpretation information providing a definition of an input document, and a 
definition of an output document, the definitions of the input and output 
documents comprising respective descriptions of sets of storage units and 
logical structures for the sets of storage units. 

2. The interface of claim 1 , wherein the interpretation information 
includes data type specifications for at least one logical structure m the 
definitions of the input and output documents. 

3. The interface of claim 1 , wherem the interpretation iirformation 
includes at least one data structure mapping predefined sets of storage units for a 
particular logical structure in the definitions of the input and output documents, 
to respective entries in a list. 

4. The interface of claim 1, including a repository in memory 
accessible by at least one node in the network storing a library of logical 
structures, and interpretation information for logic structures. 

5. The interface of claim 1 , wherein the machine readable 
specification includes a document compliant with a definition of an interface 
document including logical structures for storing an identifier of a particular 
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transaction, and at least one of definitions and references to definitions of input 
and output documents for the particular transaction. 

6. The interface of claim 1, wherein the machine readable 
specification includes a document compliant with a definition of an interface 
document including logical structures for storing an identifier of the mterface, 
and for storing at least one of specifications and references to specifications of a 
set of one or more transactions supported by the interface. 

7. The interface of claim 6, wherein the machine readable 
specification includes a reference to a specification of a particular transaction, 
and the specification of the particular transaction includes a document includmg 
logical structures for storihg at least one of definitions and references to 
definitions of input and output documents for the particular transaction. 

8. The interface of claim 1, wherein the storage units comprise 
parsed data, 

9. The interface of claim 8, wherein the parsed data in at least one 
of the input and output documents comprises: 

character data encoding text characters in the one of the input and output 
documents, and 

markup data identifying sets of storage units according to the logical 
structure of the one of the input and output documents. 

1 0. The interface of claim 9, wherein at least one of the sets of 
storage units encodes a plurality of text characters providing a natural language 
word. 
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1 1 . The interface of claim 8, wherein the interpretation information 
for at least one of the sets of storage units identified by a particular logical 
structure of at least one of the input and output documents, encodes respective 
definitions for sets of parsed characters. 

12. The interface of claim 8, wherein the storage xrnits comprise 
uhparsed data. 

1 3 . The interface of claim 1 , including a repository stored in memoiy 
accessible by at least one node in the network of docimient types for use in a 
plurality of transactions, and wherein the definition of one of the input and 
output documents includes a reference to a document type in the repository. 

1 4. The method of claim 1 3 , wherein the repository, of document 
types includes a document type for identifying participant processes in the 
networic. 

1 5. The interface of claim 1 , wherein the definitions of the input and 
output documents comprise document type definitions compliant with a 
standard Extensible Markup Language XML. 

1 6. The interface of claim 1 , wherein the machine readable data 
structure including interpretation information comprises a document organized 
according to a document type definition compliant with a standard Extensible 
Markup Language XML. 
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17. Apparatus for establishing participant interfaces for transactions 
executed on a system including a network interface and a data processing 
resources which execute a transaction processes of the transactions according to 
a transaction processing architecture; comprising: 

programs of instructions executable by the system, stored on a medium 
accessible by the system, providing tools to build a definition of a participant 
interface for a participant in a particular transaction, the definition of a 
participant interface including a definition of an input document for the 
participant and a definition of an output docxunent for the participant, the 
defmitions of the input and output documents comprising respective machine- 
readable descriptions of sets of storage units and logical structures for the sets of 
storage units; and 

programs of instructions executable by the system, stored on a medium 
accessible by the system and responsive to the definitions of the input and 
output documents, to compile data structures corresponding to the sets of 
storage units and logical structures of the input and output documents 
compliant with the transaction processmg architecture, to compile instructions 
executable by the system to translate the input document to the conresponding 
data structures, and to compile instructions executable by tiie system to translate 
ouq)ut of the transaction processes into the sets of storage units and logical 
structures of the output document. 

1 8. The apparatus of claim 1 7, wherein the tools to build a definition 
of a participant interface include instructions executable by the system to access 
elements of the definition fi-om a repository, the repository storing a library of 
logical structures, and interpretation information for logic structures used to 
build interface descriptions. 
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1 9. The apparatus of claim 1 8, wherein the repository stores 
definitions of documents comprising logic structures. 

20. The apparatus of claim 17, wherein the tools to build a definition 
of a participant interface include instructions executable by the system 

to access a definition of another participant interface for a 
complementary transaction, the accessed definition including a definition of an 
input document for the complementary transaction, and a definition of an output 
document for the complementary transaction; and 

to establish the definition of the participant interface by including the 
definition of the output document of the complementary transaction as the 
definition of the input document of the interface being built. 

21. The apparatus of claim 20, wherein the tools to build a definition 
of a participant interface include instructions executable by the system 

to include the definition of the input document of the complementary 
transaction as the definition of the output document of interface being built. 

22. The apparatus of claim 17, wherein the tools to build a definition 
of a participant interface include instructions executable by the system to build a 
document compliant with a definition of a participant interface docimient 
including logical structures for storing an identifier of a particular transaction, 
and at least one of definitions and references to definitions of input and ou^ut 
documents for the particular transaction. 

23 . The apparatus of claim 1 7, wherein the tools to build a definition 
of a participant interface include instructions executable by the system to build a 
document compliant with a definition of a participant interface document 
including logical structures for storing an identifier of the participant interface, 



-123- 



wo 00/23925 



PCT/US99/23426 



and for storing at least one of specifications and references to specifications of a 
set of one or more transactions supported by the participant interface. 

24. The apparatus of claim 23, wherein the a document compliant 
with a definition of a participant interface document includes a reference to a 
machine-readable specification of a particular transaction, and the specification 
of the particular transaction includes a document including logical structures for 
storing at least one of definitions and references to definitions of input and 
output documents for the particular transaction. 

25. The apparatus of claim 17, wherein the storage xmits comprise 
parsed data. 

26. The apparatus of claim 25, wherein the parsed data in at least one 
of the mput and output documents comprises: 

character data encoding text characters in the one of the input and output 
documents, and 

markup data identifymg sets of storage units according to the logical 
structure of the one of the input and ou^ut documents. 

27. The apparatus of claim 26, wherein at least one of the sets of 
storage units encodes a plurality of text characters providing a natural language 
word. 

28. The apparatus of claim 25, wherein the specification includes 
interpretation information for at least one of the sets of storage units identified 
by the logical structure of at least one of the input and output documents, 
encoding respective definitions for sets of parsed characters. 
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29. The apparatus of claim 25, wherein the storage units comprise 
unparsed data. 

30. The apparatus of claim 1 7, wherein data structures corresponding 
to the sets of storage units and logical structures of the input and output 
documents include programming objects including variables and methods 
according to the variant transaction processing architecture. 

3 1 . The apparatus of claim 17, wherein the variant transaction 
processing architectures of the transaction process includes comprises a process 
compliant with an interface description language, 

32. The apparatus of claun 1 7, wherein the definitioiis of the iapnt 
and output documents comprise document type definitions compliant with a 
standard Extensible Markup Language XML. 

33. The apparatus of claim 19, wherein the definition of one of the 
input and output documents includes a reference to a document type ul the 
repository. 

34. The apparatus of claim 1 8, wherein the repository includes 
interpretation information specifying measurements of products subject of 
transactions. 

3 5 . The apparatus of claim 1 8, wherein the repository includes 
interpretation information specifying costs of products subject of transactions. 
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36. The apparatus of claim 18, wherein the repository includes 
interpretation information specifying features of products subject of 
transactions. 

37. The apparatus of claim 1 8, wherein the repository mcludes 
interpretation information specifying financial terms of transactions. 

38. The apparatus of claim 1 8, wherein'the repository includes 
interpretation information specifying terms of shipment for products subject of 
transactions. 

39. Apparatus for establishing participant interfaces for transactions 
executed on a system; comprising: 

memory storing data and programs of instructions; 

a data processor coupled to the memory which executes the programs of 
. instructions; wherein the programs of instructions include 

tools to build a definition of a participant interface for a participant in a 
particular transaction, the definition of a participant interface 
including a definition of an input document for the participant 
and a definition of an output document for the participant, the 
definitions of the input and output documents comprising 
respective machine-readable descriptions of sets of storage units 
and logical structures for the sets of storage units; and 

a compiler, responsive to the defmitions of the input and output 

documents, to compile data structures corresponding to the sets 
of storage units and logical structures of the input and ou^ut 
docimients compliant with the transaction processing 
architecture, to compile instructions executable by the system to 
translate the input document to the corresponding data structures, 
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and to compile instructions executable by the system to translate 
output of the transaction processes into the sets of storage units 
and logical structures of the output document. 

40. The apparatus of claim 39, including a repository stored in 
memory accessible by the data processor, and wherein the tools to build a 
definition of a participant interface include instructions executable by the 
system to access elements of the defmition from the repository, the repository 
storing a library of logical structures, and interpretation information for logic 
structures used to build interface descriptions. 

41 . The apparatus of claim 40, wherein the repository stores 
definitions of documents comprising logic structures. 

42. The apparatus of claim 39, wherein the tools to build a definition 
of a participant mterface include instructions executable by the system 

to access a definition of another participant interface for a 
complementary transaction, the accessed definition including a definition of an 
input document for the complementary transaction, and a definition of an output 
document for the complementary transaction; and 

to establish the definition of the participant interface by including the 
definition of the output document of the complementary transaction as the 
definition of the input document of the interface being built. . 

43. The apparatus of claim 42, wherein the tools to build a defmition 
of a participant interface include instructions executable by the system 

to include the definition of the input document of the complementary 
transaction as the definition of the output document of interface being built. 
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44. The apparatus of claim 39, wherein the tools to build a definition 
of a participant interface include instructions executable by the system to build a 
document compliant with a definition of a participant interface document 
including logical structures for storing an identifier of a particular transaction, 
and at least one of definitions and references to definitions of input and output 
documents for the particular transaction. 

45. The apparatus of claim 39, wherem the tools to build a definition 
of a participant interface include instructions executable by the system to build a 
document compliant with a definition of a participant interface document 
including logical structures for storing an identifier of the participant interface, 
and for storing at least one of specifications and references to specifications of a 
set of one or more transactions supported by the participant interface. 

46. The apparatus of claim 45, wherein the a document compliant 
with a definition of a participant interface document includes a reference to a 
machine-readable specification of a particular transaction, and the specification 
of the particular transaction includes a document including logical structures for 
storing at least one of definitions and references to definitions of input and 
output documents for the particular transaction. 

47. The apparatus of claim 39, wherein the storage units comprise 
parsed data. 

48. The apparatus of claim 47, wherein the parsed data in at least one 
of the input and output documents comprises: 

character data encoding text characters in the one of the input and output 
documents, and 
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markup data identifying sets of storage units according to the logical 
structure of the one of the input and output documents, 

49. The apparatus of claim 48, wherein at least one of the sets of 
storage imits encodes a plurality of text characters providing a natural language 
word. 

50. The apparatus of claim 47, wherein the specification includes 
interpretation information for at least one of the sets of storage units identified 
by the logical structure of at least one of the input and output documents, 
encoding respective definitions for sets of parsed characters. 

5 1 . The apparattus of claim 47, wherein the storage units comprise 
unparsed data. ^ 

52. The apparatus ofclaim 39, wherein data structures corresponding 
to the sets of storage units and logical structures of the input and output 
documents include programming objects including variables and methods 
according to the variant transaction processing architecture. 

53. The apparatus of claim 39, wherein the variant transaction 
processing architectures of the transaction process comprises a process 
compliant with an interface description language. 

54. The apparatus of claim 39, wherein the definitions of the input 
and output documents comprise document type definitions compliant with a 
standard Extensible Markup Language XML. 
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55. The apparatus of claim 41, wherein the definition of one of the 
input and ou^ut documents includes a reference to a dociiment type in the 
repository. 

56. The apparatus of claim 40, wherein the repository includes 
interpretation information specifying measurements of products subject of 
transactions. 

57. The apparatus of claim 40, wherein the repository includes 
interpretation information specifying costs of products subject of transactions. 

58. The apparatus of claim 40, wherein the repository includes 
interpretation information specifying features of products subject of 
transactions. 

59. The apparatus ofclaim 40, wherein the repository includes 
interpretation information specifying fmancial terms of transactions. 

60. The apparatus ofclaim 40, wherein the repository includes 
interpretation information specifying terms of shipment for products subject of 
transactions. 

61. A method for programming a commercial transaction m a 
network, comprising: 

defining a machine readable definition of an input document for a node 
in the network including resources to execute a process in the transaction, and a 
machine readable definition of an output document for the node, the definitions 
of the input and output documents comprising respective descriptions of sets of 
storage units and logical structures for the sets of storage units; and 
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providing interpretation information for the logical structures to the 

node. 

62. The method of claim 61 , wherein the interpretation information 
includes data type specifications for at least one logical structure in the 
definitions of the input and output documents. 

63. The method of claim 61, wherein the interpretation mformation 
includes at least one data structure mapping predefined sets of storage units for a 
particular logical structure in the definitions of the input and output documents, 
to respective entries in a list 

64. The method of claim 6 1 , the step of providmg mteipretation 
information includes providing a repository in memory accessible by at least one 
node in the network storing a library of logical structures, and interpretation 
information for logic structures. 

65. The method of claim 61 , mcluding defining a machine readable 
specification of an interface includmg a document compliant with a definition of 
an interface document mcluding logical structures for storing an identifier of a 
particular transaction, and at least one of the definitions and references to the 
definitions of the input and output document. 

The method of claim 61, wherein the storage units comprise 

67. The method of claim 66, wherein the parsed data in at least one 
of the input and output documents comprises: 



66. 

parsed data. 
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character data encoding text characters in the one of the input and output 
documents, and 

markup data identifying sets of storage units according to the logical 
structure of the one of the input and output documents. 

68. The method of claim 67, wherein at least one of the sets of 
storage units encodes a plurality of text characters providing a natural language 
word. 

69. The method of claim 67, wherein the interpretation information 
for at least one of the sets of storage units identified by a particular logical 
structure of at least one of the input and output documents, encodes respective 
definitions for sets of parked characters. 

70. The method of claim 66, wherein the storage units comprise 
unparsed data. 

7 1 . The method of claim 6 1 , wherein the definitions of the input and 
output documents comprise document type definitions compliant with a 
standard Extensible Markup Language XML. 

72. The method ofclaim 61, including: 

providing a parser to generate event signals in response to logical 
structures in the definition of the input document; and 

providing event listener programs which respond to the event signals to 
execute the process. 
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73. A method for executing transactions among nodes in a network 
including a plurality of nodes which execute processes involved in the 
transactions, comprising: 

storing a machine-readable specification of an interface for a 
transaction, the specification including a defmition of an input document, and a 
definition of an output document, the definitions of the input and output 
documents comprising respective descriptions of sets of storage units and 
logical structures for the sets of storage units; 

receiving data comprising a document through a communication 
network; 

parsmg the document according to the specification to identify an mput 
document; 

providing at least a portion of the input document in a machine-readable 
format to a transaction process which produces an output; 

forming, based on the specification, an output document comprising the 
ou^ut according to the definition of an output document; and 

transmitting the output document on the communication network. 

74. The method of claim 73, including: 

accessmg a specification of a complementary interface provided for 
anotiier node in the network for the transaction, the accessed specification 
including a definition of an input document for the complementary interface, 
and a definition of an output document for the complementary interface; and 

establishing the stored specification of the interface by including at least 
part of the definition of the output document of the complementary interface in 
the definition of the mput document of the interface in the stored specification. 

75. The method of claim 74, including: 
finding the complementary interface in the network. 
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76. The method of claim 74, wherein the establishing the stored 
specification includes accessing elements of the machine-readable specification 
fi-om a repository, the repository storing a library of logical structures, schematic 
maps for logic structures, and definitions of documents comprising logic 
structures used to build interface descriptions. 

77. The method of claim 74, including: 

establishing the stored specification of the interface by includuig at least 
part of the definition of the input document of the complementary interfece in 
the defmition of the output document of the interface in the stored 
specification. 

78. The method of claim 73, including providmg access to the 
specification through the conununication network to other nodes in the network. 

79. The method of claim 73, including sending the specification of 
the interfece to another node in the network, at which access to the specification 
is provided for othernodes in the network. 

80. The method of claim 73, wherein the machine-readable 
specification includes a document compliant with a definition of an interface 
document including logical structures for storing an identifier of a particular 
transaction, and at least one of definitions and references to definitions of input 
and output documents for the particular transaction. 
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8 1 . The method of claim 73 , wherein the machine-readable 
specification includes a document compliant with a definition of an interface 
document including logical structures for storing an identifier of the interface, 
and for storing at least one of specifications and references to specifications of a 
set of one or more transactions supported by the interface. 

82. The method of claim 8 1 , wherein the machine-readable 
specification includes a reference to a specification of a particxilar transaction, 
and the specification of the particular transaction mcludes a document including 
logical structures for storing at least one of definitions and references to 
definitions of input and output docimients for the particular transaction. 

83 . The method of claim 73, wherein the storage units comprise 
parsed data. 

84. The method of claim 83, wherein the parsed data in at least one 
of the input and output documents comprises: 

character data encoding text characters in the one of the input and ou^ut 
documents, and 

markup data identifying sets of storage units according to the logical 
structure of the one of the input and output documents. 

85. The method of claim 84, wherein at least one of the sets of 
storage units encodes a plurality of text characters providing a natural language 
word. 
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86. The method of claim 83, wherein the specification includes 
interpretation information for at least one of the sets of storage units identified 
by the logical structure of at least one of the input and output documents, 
encoding respective definitions for sets of parsed characters. 

87. The method of claim 83, wherein the storage imits comprise 
unparsed data. 

88. The method of claim 73, wherein the transaction process has a 
variant transaction processing architecture, and including translating at least of 
portion of the input document into a format readable according to the variant 
transaction processing ardhitecture of the transaction process, 

r 

89. The method of claim 88, wherem the translating includes 
producmg programming objects including variables and methods according to 
the variant transaction processing architecture of the transaction process. 

90. The method of claim 88, wherein the variant transaction 
processing architecture of the transaction process includes a process compliant 
with an interface description language. 

9 1 . The method of claim 73 , wherein the definitions of the input and 
output documents comprise document type definitions compUant with a 
standard Extensible Markup Language XML. 
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92. The method of claim 73, including providing a repository of 
document types for use in a plurality of transactions, and wherein the definition 
of one of the input and output documents includes a reference to a document 
type in the repository. 

93 . The method of claim 92, wherein the repository of document 
types includes a document type for identifying participant processes in the 
network. 

94. The method of claim 92, including providing a repository of 
interpretation information for logical structures, including interpretation 
information identifying parameters of transactions. 

95. The method of claim 73, wherein the transaction process has 
variant transaction processing architecture, and including: 

accessing a specification of a complementary interface, the accessed 
specification including a definition of an input document for the 
complementary interface, and a definition of an output document for the 
complementary interface; 

establishing the stored specification of the interface by including the 
definition of the output document of the complementary interface as the 
definition of the input document of the interface in the stored specification; and 

compiling in response to the definitions of the input and output 
documents, data structures corresponding to the sets of storage units and logical 
structures of the input and output documents compliant with the transaction 
processing architecture of the transaction process, instructions executable by 
the system to translate the input document to the corresponding data structures, 
and instructions executable by the system to translate output of &e transaction 
process into a form compliant with the definition of the output document. 
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96. The method of claim 95, including: 

establishing the stored specification of the interface by including the 
definition of the input document of the complementary interface as the 
definition of the output document of the interface in the stored specification. 

97. The method of claim 73, wherein the transaction process has a 
variant transaction processing architecture, and wherein the establishing the 
stored specification includes accessing elements of the machine-readable 
specification fi-om a repository, the repository storing a library of logical 
structures, schematic maps for logical structures, and definitions of documents 
comprising logical structures used to build interface descriptions; and including 

compiling in response to the definitions of the input and output 
documents, data structuieis corresponding to the sets of storage units and logical 
structures of the input and output documents compliant with the transaction 
processing architecture of the transaction process, instructions executable by 
die system to translate the input dociunent to the corresponding data structures, 
and instructions executable by the system to translate output of the transaction 
process into a form compliant with the definition of the output document. 

98. Apparatus for managing transactions among nodes in a network 
including a plurality of nodes which execute processes involved in the 
transactions, comprising: 

a network interface; 

memory storing data and programs of instructions, including a machine- 
readable specification of an interface for a transaction, the specification 
including a definition of an input document, and a definition of an output 
document, the definitions of the input and output documents comprising 
respective descriptions of sets of storage units and logical structures for the sets 
of storage units; 
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a data processor coupled to the memory and the network interface which 
executes the programs of instructions; wherein the programs of instructions 
include 

logic to receive data comprising a document through a network 
interface; 

logic to parse the document according to the specification to identify an 
input document; 

logic to provide at least a portion of the input document in a machine- 
readable format to a transaction process which produces an 
ou^ut; 

logic to form, based on the specification, an output document 

comprising the output according to the definition of an output 
document; and 

logic to transmit the output document on the network interface. 

99. The apparatus of claim 98, including: 

logic to access a specification of a complementary interface, the 
accessed specification including.a definition of an input document for the 
complementary interface, and a definition of an output document for the 
complementary mterface; and 

logic to establish the stored specification of the interface by including 
the definition of the output document of the complementary interface as the 
definition of the input document of the interface in the stored specification. 

1 00. The apparatus of claim 99, wherein the logic to establish the 
stored specification includes logic to access elements of the machine-readable 
specification fi-om a repository, the repository storing a library of logical 
structures, schematic maps for logic structures, and definitions of documents 
comprising logic structures used to build interface descriptions. 
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101. The apparatus of claim 99, including: 

logic to establish the stored specification of the interface by including 
the definition of the input document of the complementary interface as the 
definition of the output document of the interface in the stored specification. 

102. The apparatus of claim 98, including logic to provide access to 
the specification through the network interface to other nodes in the network. 

103. The apparatus of claim 98, including logic to send the 
specification of the interface to another node in the network, at vdiich access to 
the specification is provided for other nodes in the network. 

104. The apparatus of claim 98, wherein the machine-readable 
specification includes a document compliant with a definition :of an interface 
document including logical structures for storing an identifier of a particular 
transaction, and at least one of definitions and references to definitions of input 
and output documents for the particular transaction. 

105. The apparatus of claim 98, wherem the machine-readable 
specification includes a document compliant with a definition of an interface 
document including logical structures for storing an identifier of the interface, 
and for storing at least one of specifications and references to specifications of a 
set of one or more transactions supported by the interface. 

106. The apparatus of claim 105, wherein the machine-readable 
specification includes a reference to a specification of a particular transaction, 
and the specification of the particular transaction includes a document including 
logical structures for storing at least one of definitions and references to 
definitions of mput and output documents for the particular transaction. 
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107. The apparatus of claim 98, wherein the storage units comprise 
parsed data. 

1 08. The apparatus of claim 1 07, wherein the parsed data in at least 
5 one of the input and output documents comprises: 

character data encoding text characters in the one of the input and output 
documents, and 

markup data identifying sets of storage units according to the logical 
structure of the one of the input and output documents. 

10 

1 09. The apparatus of claim 108, wherein at least one of the sets of 
storage imits encodes a plurality of text characters providmg a natural language 
word. 

15 110. The apparatus of claim 1 07, wherein the specification includes 

interpretation information for at least one of the sets of storage units identified 
by the logical structure of at least one of the mput and output documents, 
encoding respective definitions for sets of parsed characters. 

20 111. The apparatus of claim 1 07, wherein the storage units comprise 

unparsed data. 

1 12. The apparatus of claim 98, wherein the transaction process has 
variant transaction processing architecture, and including logic to translate at 
25 least of portion of the input document into a format readable according to the 

variant transaction processing architecture of the transaction process. 
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113. The apparatus of claim 112, wherein the logic to translate 
includes logic to produce programming objects including variables and methods 
according to the variant transaction processing architecture of the transaction 
process. 

1 14. The apparatus of claim 1 12, wherein the variant transaction 
processing architecture of the transaction process includes a process compliant 
with an interface description language. 

115. The apparatus of claim 98, wherein the definitions of the input 
and output documents comprise document type definitions compliant with a 
standard Extensible Markup Language XML. 

116. The apparatus of claim 98, including memory ^accessible by the 
processor storing a repository of document types for use in a plurality of 
transactions, and wherein the definition of one of the input and output 
documents includes a reference to a document type in the repository. 

117. The apparatus of claim 1 16, wherein the repository of document 
types includes a document type for identifying participant processes in the 
network. 

118. The apparatus of claim 1 16, including providing a repository of 
interpretation information for logical structures, including interpretation 
information identifying parameters of transactions. 

119. The apparatus of claim 98, wherein the transaction process has 
variant transaction processing architecture, and including: 
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logic to access a specification of a complementary interface, the 
accessed specification including a definition of an input document for the 
complementary interface, and a definition of an output document for the 
complementary interface; 

logic to establish the stored specification of the interface by including 
the definition of the output document of the complementary mterface as the 
definition of the input document of the interface in the stored specification; and 

logic to compile in response to the definitions of the input and output 
documents, data structures corresponding to the sets of storage units and logical 
structures of the input and output documents compliant with the transaction 
processing architecture of the transaction process, to compile instructions 
executable by the system to translate the input document to the corresponding 
data structures, and to compile instructions executable by the system to 
translate output of the transaction process into a form compliant with the 
definition of the ouq)ut document 

120. The apparatus of claim 1 1 9, including: 

logic to establish the stored specification of the interface by including 
the definition of the input document of the complementary interface as the 
definition of the output document of the interface in the stored specification. 

121. The apparatus of claim 98, wherein the transaction process has a 
variant transaction processing architecture, and including logic to establish the 
stored specification by accessing elements of the machine^readable specification 
from a repository, the repository storing a library of logical structures, 
schematic maps for logical structures, and definitions of documents comprising 
logical structures used to build interface descriptions; iand including 

logic to compile in response to the definitions of the input and output 
documents, data structures corresponding to the sets of storage units and logical 

- 143 - 



SUBSTITUTE SHEET (RULE 26) 



Wd 00/23925 



PCT/US99/23426 



Structures of the input and output documents compliant with the transaction 
processing architecture of the transaction process, to compile instructions 
executable by the system to translate the input document to the corresponding 
data structures, and to compile instructions executable by the system to translate 
ou^ut of the transaction process into a form compliant with the definition of the 
output document - 

122. A method for managing transactions among nodes in a network 
including a plurality of nodes which execute processes involved in the 
transactions, comprising: 

storing machine-readable specifications of a plurality of participant 
interfaces, the participant interfaces identifying transactions, the respective 
transactions being identified by definitions of input documents, and definitions 
of output documents, the definitions of the input and output docimients 
comprising respective descriptions of sets of storage units and logical structures 
for the sets of storage units; 

receiving data comprising a document through a communication 
network; 

parsing the document according to the specifications to identify an input 
document and one or more transactions which accept the identified mput 
document; 

providing at least a portion of the input document in a machine-readable 
format to transaction processes associated with the one or more identified 
transactions. 

123. The method of claim 122, including: 

providing a repository storing a library of logical structures, schematic 
maps for logic structures, and definitions of documents comprising logic 
structures used to build participant interface descriptions. 
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124. The method of claim 123, including providing access to the 
repository through the communication network to other nodes in the network. 

125. The method of claim 122, wherein the machine-readable 
specification includes documents compliant with a definition of a participant 
interface document including logical structures for storing an identifier of a 
particular transaction, and at least one of definitions and references to 
definitions of input and output documents for the particular transaction. 

126. The method of claim 122, wherein the machine-readable 
specifications include documents compliant with a definition of a participant 
interface document including logical structures for storing an identifier of the 
participant interface, and for storing at least one of specifications and references 
to specifications of a set of one or more transactions supported by the 
participant interface. 

127. The method of claim 126, wherein the documents compliant with 
a defmition of a participant interface document include a reference to a 
specification of a particular transaction, and the specification of the particular 
transaction includes a document including logical structures for storing at least 
one of definitions and references to definitions of input and output documents 
for the particular transaction. 

128. The method of claim 122, wherein the storage imits comprise 
parsed data. 
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, 129. The method of claim 128, wherein the parsed data in at least one 
of the input and output documents comprises: 

character data encoding text characters in the one of the input and output 
documents, and 

markup data identifying sets of storage units according to the logical 
structure of the one of the input and output documents^ 

130. The method of claim 129, wherein at least one of the sets of 
storage units encodes a plurality of text characters providing a natural language 
word. 

131. The method of claim 1 3 0, wherein the specification includes 
interpretation information for at least one of the sets of storage units identified 
by the logical structure of at least one of the input and output documents, 
encoding respective definitions for sets of parsed characters. 

132. The method of claim 130, wherein the storage units comprise 
unparsed data. 

133. The method of claim 1 22, wherein the providing at least a 
portion of the input document in a machine-readable format to transaction 
processes associated with the one or more identified transactions includes 
executing a routing process according to a processing architecture, and 
including: 

compiling m response to the definitions of the input and output 
documents in the participant interfaces, data structures corresponding to the sets 
of storage units and logical structures of the input and output documents 
compliant with the processing architecture of the transaction process, 
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instructions executable by the system to translate the input document to the 
corresponding data structures. 

134. The method of claim 122, wherein the providing at least a 
portion of the input document in a machine-readable format to transaction 
processes associated with the one or more identified transactions includes 
executing a routing process according to a processing architecture, and 
including translating at least of portion of the incoming document into a fonnat 
readable according to the processing architecture. 

135. The method of claim 134, wherein the translating includes 
producing programming objects including variables and methods according to 
the processing architecture of the routing process. 

136. The method of claim 122, wherein providing at least a portion of 
the input document in a machine-readable format to transaction processes 
associated with the one or more identified transactions, includes routing the 
portion of the input document to the identified transactions. 

137. The method of claim 1 36, wherein the routing includes sending 
the input document on the communication network to a node executing one of 
the identified transactions. 

138. The method of claim 122, wherein the definitions of the input 
and output documents comprise document type definitions compliant with a 
standard Extensible Markup Language XML. 
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139. The method of claim 138, wherein the specifications of 
participant interfaces comprise definitions of documents according to document 
type definitions compliant with a standard Extensible Markup Language XML. 

140. The method of claim 122, wherein the repository includes 
standardized document types for use in a plurality of transactions, and wherein 
the definition of one of the input and output documents includes a reference to a 
standardized docxunent type in the repository. 

141 . The method of claim 140, wherein the repository includes a 
standardized document type for identifying participant processes in the network. 

142. The method of claim 140, including providing a repository of 
interpretation information for logical structures, including interpretation 
information identifying parameters of transactions. 

143. The method of claim 122, wherein the transaction processes have 
respectively one of a plurality of variant transaction processing architectures, 
and including translating at least of portion of the incoming docimient into a 
format readable according to the variant transaction processing architecture of 
the respective transaction processes, and routing the translated portion to the 
respective transaction processes. 

144. The method of claim 143, wherein the translating includes 
producing programming objects including variables and methods according to 
the variant transaction processing architecture of the respective transaction 
processes. 
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145. The method of claim 144, wherein the variant transaction 
processing architectures of the transaction processes comprises a process 
compliant with an interface description language. 

146. Apparatus for managing transactions among nodes in a network 
including a plurality of nodes which execute processes involved in the 
transactions, comprising: 

a network interface; 

memory storing data and programs of instructions, including machine- 
readable specifications of a plurality of participant interfaces, the participant 
interfaces identifying transactions, the respective transactions being identified 
by definitions of input documents, and definitions of output documents, the 
definitions of the input and output documents comprising respective 
descriptions of sets of storage units and logical structures for the sets of storage 
units; 

a data processor coupled to the memory and the network interface which 
executes the programs of instructions; wherein the programs of instructions 
include 

logic to receive data comprising a document through a network 
interface; 

logic to parse the document according to the specifications to identify 
an input document and one or more transactions which accept the 
identified input docimient; and 

logic to'provide at least a portion of the input document in a machine- 
readable format to transaction processes associated with the one 
or more identified transactions. 
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147. The apparatus of claim 146, including a repository stored in 
memory accessible by the data processor storing a library of logical structures, 
schematic maps for logic structures, and definitions of documents comprising 
logic structures used to build participant interface descriptions. 

148. The apparatus of claim 146, including logic to access a 
repository stored in memory through the network interface storing a library of 
logical structures, schematic maps for logic structures, and definitions of 
documents comprising logic structures used to build participant interface 
descriptions. 

149. The apparatus of claim 146, vvherein the machine-readable 
specification includes documents compliant with a definition of a participant 
interface document including logical structures for storing an identifier of a 
particular transaction, and at least one of definitions and references to 
definitions of input and output documents for the particular transaction. 

150. The apparatus of claim 146, wherein the machine-readable 
specifications include documents compliant with a definition of a participant 
interface document including logical structures for storing an identifier of the 
participant interface, and for storing at least one of specifications and references 
to specifications of a set of one or more transactions supported by the 
participant mterface. 

151. The apparatus of claim 1 50, wherein the documents compliant 
with a definition of a participant interface document include a reference to a 
specification of a particular transaction, and the specification of the particular 
transaction includes a document including logical structures for storing at least 
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one of definitions and references to definitions of input and output documents 
for the particular transaction. 

1 52. The apparatus of claim 1 46, wherein the storage imits comprise 
parsed data. 

1 53 . The apparatus of claim 1 52, wherein the parsed data in at least 
one of the input and output documents comprises: 

character data encoding text characters in the one of the input and output 
documents, and 

markup data identifying sets of storage units according to the logical 
structure of the one of the input and output documents. 

1 54. The apparatus of claim 1 53, wherein at least one of the sets of 
storage units encodes a plurality of text characters providing a natural language 
word. 

1 55. The apparatus of claim 1 54, wherein the specification includes 
mterpretation information for at least one of the sets of storage units identified 
by the logical structure of at least one of the input and output documents, 
encoding respective definitions for sets of parsed characters. 

1 56. The apparatus of claim 1 54, wherein the storage units comprise 
unparsed data. 

1 57. The apparatus of claim 1 46, wherein the logic to provide at least 
a portion of the input dociunent in a machine-readable format to transaction 
processes associated with the one or more identified transactions includes a 
routing process according to a processing architecture, and including: 
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a compiler responsive to the definitions of the input and output 
documents in the participant interfaces, to compile data structures 
corresponding to the sets of storage units and logical structures of the input and 
output documents compliant with the processing architecture of the transaction 
process, and to compile instructions executable by the system to translate the 
input document to the corresponding data structures. 

158. The apparatus of claim 146, wherein the logic to provide at least 
a portion of the input document in a machine-readable format to transaction 
processes associated with the one or more identified transactions includes a 
routing process according to a processing architecture, and including logic to 
translate at least of portion of the incoming document into a format readable 
according to the processing architecture, 

159. The apparatus of claim 158, wherein the logic to translate 
mcludes producing programming objects including variables and methods 
according to the processing architecture of the routing process. 

160. The apparatus of claim 146, wherein logic to provide at least a 
portion of the input document in a machine-readable format to transaction 
processes associated with the one or more identified transactions, includes a 
router to route the portion of the input document to the identified transactions. 

161. The apparatus of claim 1 60, wherein the router includes logic to 
send the input document on the network interface to a node executing one of 
the identified transactions. 
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1 62. The apparatus of claim 1 46, wherein the definitions of the input 
and output documents comprise document type definitions compliant with a 
standard Extensible Markup Language XML. 

1 63. The apparatus of claim 1 62, wherein the specifications of 
participant interfaces comprise definitions of documents according to document 
type definitions compliant with a standard Extensible Markup Language XML. 

164. The apparatus of claim 147, wherein the repository includes 
standardized docxmient types for use in a plurality of transactions, and wherein 
the definition of one of the inputand output documents includes a reference to a 
standardized document type in the repository. 

165. The apparatus of claim 147, wherem the repository includes a 
standardized document type for identifying participant processes in the network. 

1 66: The apparatus of claim 1 46, wherein the transaction processes 
have respectively one of a plurality of variant transaction processing 
architectures, and including logic to translate at least of portion of the incoming 
document into a format readable according to the variant transaction processing 
architecture of the respective transaction processes, and to route the translated 
portion to the respective transaction processes. 

1 67. The apparatus of claim 1 66, wherein the logic to translate 
produces programming objects mcluding variables and methods according to 
the variant transaction processing architecture of the respective transaction 
processes. 
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168. The apparatus of claim 166, wherein the variant transaction 
processing architectures of the transaction processes comprises a process 
compliant with an interface description language. 
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